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Foreword 

This Technical Specification has been produced by the 3"* Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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1 Scope 

The present document is part of a series of documents that specify charging functionality and charging management in 
GSM/UMTS networks. The GSM/UMTS core network charging architecture and principles are specified in document 
TS 32.240 [1], which provides an umbrella for other charging management documents that specify: 

- the content of the CDRs per domain and subsystem (offline charging), 

- the content of real-time charging events per domain / subsystem (online charging); 

- the fimctionaUty of online and offline charging for those domains and subsystems; 

- the interfaces that are used in the charging framework to transfer the charging information (i.e. CDRs or charging 
events) 

The complete document structure for these TSs is defined in TS 32.240 [1]. 

The present document specifies the Offline and Online Charging description for the IP Multimedia Subsystem (IMS), 
based on the functional descriptions of the IMS in 3GPP TS 23.228 [200]. This charging description includes the offline 
and online charging architecture and scenarios specific to IMS, as well as the mapping of common 3GPP charging 
architecture specified in TS 32.240 [1] onto IMS. It further specifies the structure and content of the CDRs for offline 
charging, and the charging events for online charging. The present document is related to other 3GPP charging TSs as 
follows: 

■ The common 3GPP charging architecture is specified in TS 32.240 [1]; 

■ The parameters, abstract syntax and encoding rules for these CDR types are specified in TS 32.298 [51]. 

■ A transaction based mechanism for the transfer of CDRs within the network is specified in TS 32.295 [54]. 

■ The file based mechanism used to transfer the CDRs from the network to the operator's billing domain (e.g. 
the billing system or a mediation device) is specified in TS 32.297 [52]. 

■ The 3GPP Diameter appUcation that is used for IMS offline and online charging is specified in TS 32.299 [50]. 

All terms, definitions and abbreviations used in the present document, that are common across 3GPP TSs, are defined in 
the 3GPP Vocabulary, TR 21.905 [100]. Those that are common across charging management in GSM/UMTS domains, 
services or subsystems are provided in the umbrella document TS 32.240 [1] and are copied into clause 3 of the present 
document for ease of reading. Finally, those items that are specific to the present document are defined exclusively in 
the present document. 

Furthermore, requirements that govern the charging work are specified in 3GPP TS 22.1 15 [101]. 



2 References 

The following documents contain provisions, which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[1] 3GPP TS 32.240: "Telecommunication management; Charging management; Charging 

architecture and principles". 

[2] 3GPP TS 32.250: "Telecommunication management; Charging management; Circuit Switched 

(CS) domain charging". 
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[3] - [10] Void. 

[11] 3GPP TS 32.25 1 : "Telecommunication management; Charging management; Packet Switched 

(PS) domain charging". 

[12] - [34] Void. 

[35] 3GPP TS 32.275: "Telecommunication management; Charging management; MultiMedia 

Telephony (MMTel) charging". 

[36] 3GPP TS 32.280: " Telecommunication management; Charging management; Advice of Charge 

(AoC) service". 

[37] - [49] Void. 

[50] 3GPP TS 32.299: "Telecommunication management; Charging management; Diameter charging 

application 

[51] 3GPP TS 32.298: "Telecommunication management; Charging management; Charging Data 

Record (CDR) parameter description 

[52] 3GPP TS 32.297: "Teleconnmunication management; Charging management; Charging Data 

Records (CDR) file format and transfer 

[53] Void. 

[54] 3GPP TS 32.295: "Telecommunication management; Charging management; Charging Data 

Record (CDR) transfer". 

[55]- [99] Void. 

[100] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications". 

[101] 3GPP TS 22.115: "Service aspects; Charging and bilhng". 

[102] Void. 

[ 1 03] 3GPP TS 23 .002: "Network Architecture" . 

[104]- [199] Void. 

[200] 3GPP TS 22.228: "IMS Stage 1". 

[201] 3GPP TS 23.228: "Functional stage 2 description of IMS". 

[202] 3GPP TS 24.228: "Signalhng flows for the IP multimedia call control based on SIP and SDP, 

Stage 3" 

[203] 3GPP TS 23.218: "IP Multimedia (IM) session handhng; IM caU model; Stage 2". 

[204] 3GPP TS 24.229: "Internet Protocol (IP) multimedia call control protocol based on Session 

Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3". 

[205] 3GPP TS 29.229: "Cx and Dx Interfaces based on the Diameter protocol; Protocol Details". 

[206] 3GPP TS 29.658: "SIP Transfer of IP Multimedia Service Tariff Information". 

[207] 3GPP TS 33.203 "3G security; Access security for IP-based services" 

[208] 3GPP TS 33.210 "3G security; Network Domain Security (NDS); IP network layer security" 

[209] 3GPP TS 33.310" Network Domain Security (NDS); Authentication Framework (AF) " 

[210] 3GPP TS 24.292: "IP Multimedia (IM) Core Network (CN) subsystem CentraUzed Services (ICS); 

Stage 3". 

[211] 3GPP TS 29.079: "Optimal Media Routeing within the IP Multimedia Subsystem;Stage 3". 
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[212] 3GPP TS 23.167: "IP Multimedia Subsystem (IMS) emergency sessions". 

[213] 3GPP TS 23.203: "Policy and Charging Control architecture". 

[214]- [299] Void. 

[300]- [399] Void. 

[400] Void. 

[401] IETF RFC 3588 (2003): "diameter base protocol". 

[402] IETF RFC 4006: "Diameter Credit Control Application" . 

[403] IETF RFC 2806: "URLs for Telephone Calls" . 

[404] IETF RFC 3261: "SIP: Session Initiation Protocol". 

[405] IETF RFC 2486: "The Network Access Identifier" . 

[406] RFC 3455 (January 2003): "Private Header (P-Header) Extensions to the Session Initiation 
Protocol (SIP) for the 3rd-Generation Partnership Project (3GPP)". 

[407] 3GPP TS 23.237: " IP Multimedia Subsystem (IMS) Service Continuity; Stage 2". 

[408] 3GPP TS 24.237: " IP Multimedia Subsystem (IMS) Service Continuity; Stage 3". 



3 Definitions, symbols and abbreviations 
3.1 Definitions 

For the purposes of the present document, the following terms and definitions given in 3GPP TR 21.905 [50], 3GPP 
TS 32.240 [1], and the following apply: 

billing: function whereby CDRs generated by the charging function are transformed into bills requiring payment. 

Billing Domain: Part of the operator network, which is outside the core network that receives and processes charging 
information from the core network charging functions. It includes functions that can provide bilhng mediation and 
billing end applications. 

CDR field Categories: the CDR fields are defined in the present document. They are divided into the following 
categories: 

• Mandatory: field that shall be present in the CDR. 

• Conditional: field that shall be present in a CDR if certain conditions are met. 

• Operator Provisionable: Mandatory: A field that operators have provisioned to be included in the CDR for all 
conditions. 

• Operator Provisionable: Conditional: A field that operators have provisioned to be included in the CDR if 
certain conditions are met. 

charged party: user involved in a chargeable event that has to pay parts or the whole charges of the chargeable event, 
or a third party paying the charges caused by one or all users involved in the chargeable event, or a network operator. 

charging: function whereby information related to a chargeable event is formatted and transferred in order to make it 
possible to determine usage for which the charged party may be billed. 

Charging Data Record (CDR): record generated by a network element for the purpose of bilhng a subscriber for the 
provided service. It includes fields identifying the user, the session and the network elements as well as information on 
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the network resources and services used to support a subscriber session. In the traditional circuit domain, CDR has been 
used to denote "Call Detail Record", which is subsumed by "Charging Data Record" hereafter. 

charging function: entity inside the core network domain, subsystem or service that is involved in charging for that 
domain, subsystem or service. 

offline charging: charging mechanism where charging information does not affect, in real-time, the service rendered 

online charging: charging mechanism where charging information can affect, in real-time, the service rendered and 
therefore a direct interaction of the charging mechanism with session/service control is required 

partial CDR: CDR that provides information on part of a subscriber session. A long session may be covered by several 
partial CDRs. Two formats are considered for Partial CDRs. One that contains all of the necessary fields; the second has 
a reduced format. 

3.2 Symbols 

For the purposes of the present document, the following symbols apply: 

Bi Reference point for the CDR file transfer from the IMS CGF to the BD. 

Ga Reference point for CDR transfer between a CDF and CGF. 

Rf Offiine Charging Reference Point between an IMS Network Entity or an AS and CDF 

Ro Online Charging Reference Point between an AS or MRFC and IMS-GWF and the OCS 

3.3 Abbreviations 



For the purposes of the present document, the following abbreviations apply: 



ABNF 


Augmented Backus-Naur Form 


ACA 


Accounting Answer 


ACR 


Accounting Request 


AS 


Application Server 


ATCF 


Access Transfer Control Function 


ATGW 


Access Transfer Gateway 


AVP 


Attribute Value Pair 


B2BUA 


Back-to-Back User Agent 


BGCF 


Breakout Gateway Control Function 


BS 


Billing System 


CCA 


Credit Control Answer 


CCF 


Charging Collection Function 


CCR 


Credit Control Request 


CDF 


Charging Data Function 


CDIV 


Communication Diversion 


CDR 


Charging Data Record 


CGF 


Charging Gateway Function 


CONF 


Conference 


CPCF 


Content Provider Charging Function 


CSCF 


Call Session Control Function (I-Interrogating; P-Proxy; and S-Serving) 


EATF 


Emergency Access Transfer Fvmction 


ECF 


Event Charging Function 


ECUR 


Event Charging with Unit Reservation 


IBCF 


Interconnect Border Control Function 


lEC 


Immediate Event Charging 


IMS 


IP Multimedia Subsystem 


IMS-AGW 


IMS Access Media Gateway 


IMS-ALG 


IMS - Application Level Gateway 


IMS-GWF 


IMS Gateway Function 


lOI 


Inter Operator Identifier 


ISC 


IMS Service Control 


MGCF 


Media Gateway Control Function 


MMTel 


MultiMedia Telephony 
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MRFC 


Media Resource Function Controller 


NNI 


Network to Network Interface 


MRFP 


Multimedia Resource Function Processor 


NetLoc 


Network provided Location information 


ocs 


Online Charging System 


OMR 


Optimal Media Routing 


RTTI 


Real-time Transfer of Tariff Information 


SCCF 


Subscriber Content Charging Function 


SCUR 


Session Charging with Unit Reservation 


SDP 


Session Description Protocol 


SIP 


Session Initiation Protocol 


TIP 


Terminating Identity Presentation 


TIR 


Terminating Identity Restriction 


TRF 


Transit and Roaming Function 


TrGW 


Transition GateWay 


UA 


User Agent 


UE 


User Equipment 


vcc 


Voice Call Continuity 


VDN 


VCC Domain transfer Number 
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4 Architecture Considerations 

4.1 High level IP Multimedia Subsystem (IMS) architecture 

Figure 4.1 depicts the logical IMS architecture, as described in 3GPP TS 23.002 [103] 
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Figure 4.1 : IIUIS iogicai architecture 
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4.2 IMS offline charging architecture 

The architecture for IMS offline charging is described in the following figure. The Rf interface is described in clause 
6.1.1 and Bi in clause 6.1.2. 
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Figure 4.2: IMS offline charging architecture 
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4.3 IMS online charging architecture 

The architecture for IMS online charging is described in the following figure. The Ro interface is described in clause 
6.2 and ISC in TS 23.228 [201]. 
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Figure 4.3: IMS online charging Architecture 
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5 Charging Principles 
5.1 IMS Charging Principles 

The IMS network elements shall maintain the integrity of all received or created charging-related information when 
forwarding the information to the offline and online charging systems, whatever the length of the value of any particular 
parameter is. For example, the IMS Charging Identifier (ICID) may be generated by one IMS network element (e.g. the 
P-CSCF) and forwarded to another IMS network element (e.g. the S-CSCF). Both may generate charging information 
and ensure that the data integrity is maintained, in order to make possible correlation based on the ICID. 

5.1 .1 IMS Charging applicability 

The AS and MRFC are able to distinguish whether to apply offline or online charging, i.e. whether to send charging 
information over the Rf interface to the CDF or over the Ro interface to the OCS, which includes ECF and SCF as 
described in chapter 4.3 (or to use both). The decision of which interface to use is based on the information (CDF and/or 
OCS address) the AS/MRFC receives in the SIP signalling and the system configuration as provisioned by the operator. 
If the AS/MRFC only receive the CDF address and do not receive an OCS address then they use only the Rf interface. 
If only the OCS address was provided then they use only the Ro interface. In cases where both CDF and OCS addresses 
are provided it is possible to use both interfaces simultaneously. 

However, operators may overrule the addresses received via the SIP signalling and use their own configured rules 
instead. Operators may configure locally on the AS/MRFC an OCS and/or CDF address. The choice of whether the 
IMS network elements use locally configured addresses or the addresses received by SIP signalling, and the decision on 
which interface(s) to use, is left for operator configuration. 

All other IMS network elements (S-CSCF, P-CSCF, I-CSCF, BGCF, IBCF, and MGCF) apply offline charging via the 
Rf interface using the CDF address as received via SIP signalling or the locally configured CDF address in the IMS 
network element. The S-CSCF supports onUne charging using: 

the ISC interface, i.e. if the application server addressed over ISC is the IMS Gateway Function, or 

the Ro interface directly instead of the ISC, if the IMS Gateway Function is integrated within the S-CSCF. 

The offline and onhne charging function addresses transferred in SIP signalhng are encoded in the P-Charging- 
Function- Addresses as defined in TS 24.229 [204] and RFC 3455 [406]. The P-Charging-Function- Addresses header 
contains the following parameters: CCF (i.e. CDF) and ECF (i.e. OCS). 

5.1 .2 IMS Charging Correlation 

5.1 .2.1 Basic Principles for IMS Domain Correlation 

The IMS charging correlation information is encoded in the SIP P-Charging-Vector header as defined in the following 
sub clauses. The P-Charging- Vector header contains the following parameters: ICID, access network charging identifier 
and lOI. 

General correlation mechanisms are defined in TS 32.240 [1], and further details about the usage of P-Charging- Vector 
are defined in TS 24.229 [204], TS 24.292 [210], and RFC 3455 [406]. 

5.1 .2.2 IMS Charging Identifier (ICID) 

The IMS domain correlation is based on IMS Charging Identifier (ICID) shared between IMS network elements 
involved with the same session/transaction. With ICID it is possible to correlate session/transaction related charging 
data generated in different IMS elements (i.e. x-CSCFs, ASs'). The ICID is included in all SIP methods, if the P- 
Charging- Vector header is present, and transferred through originating and terminating side nodes, except to UE. 

The value of the ICID parameter is identical with the 'icid- value' parameter defined in TS 24.229 [204]. The 'icid- value' 

is a mandatory part of the P-Charging- Vector and coded as a text-based UTF-8 charset (as are all SIP messages). For 
further information regarding the composition and usage of the P-Charging- Vector refer to [204] and RFC 3455 [406]. 
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The ICID value is globally unique across all 3GPP IMS networks for a time period of at least one month, implying that 
neither the node that generated this ICID nor any other IMS network element reuse this value before the uniqueness 
period expires. The one month minimum uniqueness period counts from the time of release of the ICID, i.e. the ICID 
value no longer being used. This can be achieved by using node specific information, e.g. high-granularity time 
information and / or topology / location information. The exact method how to achieve the uniqueness requirement is 
an implementation issue. 

At each SIP session unrelated method, both initial and subsequent (e.g., REGISTER, NOTIFY, MESSAGE etc.), a new, 
session unrelated ICID is generated at the first IMS network element that processes the method. This ICID value is 
contained in the SIP request and response of that SIP transaction and must be valid for the duration of the transaction. 

At each SIP session estabUshment a new, session specific ICID is generated at the first IMS network element that 
processes the session-initiating SIP INVITE message. Enhanced MSC server will generate an ICID for ICS and SRVCC 
originated calls as described in TS 24.229 [204]. This ICID is then used in all subsequent SIP messages for that session 
(e.g., 200 OK, (re-)INVITE, BYE etc.) until the session is terminated. 

5.1.2.2A Related ICID 

During the process of SRVCC access transfer, the Enhanced MSC server or the P-CSCF generates an ICID for the 
target access leg. For the purpose of charging correlation between the source access leg and the target access leg when 
the user is roaming the SCC AS and the ATCF includes the ICID used on the source access leg as the Related ICID for 
the target access leg as described in TS 24.229 [204]. This Related ICID is sent in the Ixx and 2xx responses to the 
initial INVITE as described in TS 24.237 [408]. 

5.1 .2.3 Access network charging identifier 

The access network charging identifier is the media flow level data shared among the IMS network elements for one 
side of the session (either the originating or terminating side). This information is used to correlate the access network 
charging data with the IMS charging data. The access network is identified by bearer specific correlation identifier, e.g. 
for Packet Switched Access (GGSN address and PDP context Identifier) or Fixed Broadband Access (Multimedia 
Charging Identifier). The access network charging identifier is populated in the P-Charging- Vector using the access- 
network-charging-info parameter. For further information regarding the composition and usage of the access-network- 
charging-info parameter refer to TS 24.229[204] and RFC 3455 [406]. 

5.1 .2.4 Inter Operator Identifier (101) 

The lOI identifies originating, terminating and transit networks involved in a session/transaction. The lOI may be 
generated from each side of session/transaction to identify the home networks associated with each side. The orig-ioi 
and term-ioi parameters of P-Charging- Vector represent the originating and terminating operator identifiers. 

For interconnection scenarios in multi operator environments where one or more transit operators are between the 
originating and terminating operator, a list of Transit lOI values may occur additionally to identify involved transit 
operators. Due to operator policy, a transit operator may also hide his identity by adding a void value. Addition and 
deletion of transit lOI values are operator configurable. For further information regarding the composition and usage of 
the parameters refer to TS 24.229[204], TS 24.292 [210], and IETF RFC 3455 [406]. 

5.1.2.5 Void 

5.1 .2.6 IMS visited network identifier 

The IMS visited network identifier identifies the visited network involved in a session/transaction. The IMS visited 
network identifier is available in the SIP P-Visited-Network-ID header of the REGISTER and should be used for all 
charging events associated with the user. 

5.1.3 SDP handling 

SDP information on SIP can have two different meanings; SDP offer or SDP answer. This is captured in the charging 
information by a SDP-type parameter that indicates if the SDP media component is an offer or answer. SDP offers can 
be sent by either the calling or called party and the Media Initiator Flag identifies who sent the first SDP offer in a SDP 
negotiation. SDP can be negotiated more than once in an INVITE or re-INVITE dialog. 
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5.1.4 Trigger conditions 

This chapter contains the details for trigger conditions Usted in table 5.2.1.1 for Offline Charging messages (ACR) and 
5.3.1.1 for Online Charging messages (CCR) triggered by SIP Methods or ISUP Messages for all IMS nodes except for 
MRFC and AS. 

The I-CSCF and BGCF, which need not be present in the signalling path for subsequent requests after the first SIP 
INVITE, do not support session based charging using ACR [Start, Interim, and Stop]. In these (and only in these) IMS 
network elements, successful session set-up completion triggers ACR [Event]. Use of session based charging when the 
1-CSCF or the BGCF is call stateful is not described in this release. 

The initial registration, user-initiated reregistration, and user-initiated de-registration chargeable events relate to SIP 
REGISTER to trigger ACR [EventJ/CCRs, while network-initiated deregistration event relates to SIP NOTIFY to 
trigger ACR [Event]/CCRs provided that subscription to registration events has been appUed (see TS 24.229 [204]). 

If at the time when the SIP 200 OK is received only the SDP offer is available, the CTF may trigger ACR [Start] 
irmnediately (subsequent SIP ACK containing the SDP answer triggers ACR [Interim]) or may trigger ACR [Start] 
once the SIP ACK has been received. The precise behaviour shall depend on operator pohcy. 

5.1 .5 IIVIS support of real-time tariff transfer 

The TS 29.658 [206] describes the Real-time Transfer of Tariff Information (RTTI) in SIP. The RTTI may be supported 
for the requested service (e.g. tariff information of a value added service residing in the called network or in a specific 
Application Server). 

According to the procedures described in the TS 29.658 [206], tariff information may be included in the content body of 
the following SIP messages: Ixx provisional response or 200 OK at session setup, mid-dialog requests or responses. 
The following IMS network elements, IBCF, MGCF, S-CSCF and AS may pass tariff information and record the tariff 
information in the corresponding CDRs for IMS offhne charging. For online charging, the AS and the IMS-GWF may 
send charging information related to the content body of RTTI message over Ro interface to the OCS. 

The following security mechanisms shall be used for RTTI: 

- IBCF shall accept RTTI information only from trusted IMS networks and filter out RTTI information from 
non trusted IMS networks. 

- If RTTI information has to be sent over unsecure domain networks, the security of the domains 
interconnection shall rely on Network Domain Security specifications: TS 33.210 [208] and TS 33.310 [209]. 

- The S-CSCF responsible for the handling of RTTI messages shall follow the conmion IMS security 
specification TS 33.203 [207] to protect against malicious UE that try to bypass the P-CSCF. 

5.1 .6 Served user identification 

Subscription Id is a field used in both online and offline charging information to identify the served user for the specific 
leg of an IMS session. A list of Subscription ld(s) shall contain the Privateand/or Public user ld(s) for the served user. 

In the case when the served user is obtained from the P-Header P-Served-User (can be available in P-CSCF, S-CSCF 
and AS) then it shall also be used as Subscription-Id in both online and offline charging. 

5.1 .7 Single Charging session from AS acting as B2BUA 

When a session-initiating SIP INVITE message is received by an AS, this AS, per application logic needs, acting as a 
B2BUA, may decide IMS Charging Identifier (ICID) for the outgoing dialog to be the same as received or different. 

In case the same IMS Charging Identifier (ICID) is preserved between incoming and outgoing dialog by the AS acting 
as a B2BUA, a single charging session for both dialogs can be created by this AS. This option, refered-to as 
"OneChargingSession" in the different descriptions, is applicable per Operator configuration. 
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5.1 .8 Charging support for Roaming Arclnitecture for Voice over IMS witin 
Local Breakout 

The Roaming Architecture for Voice over IMS with Local Breakout is described in the TS 23.228 [201]. The 
corresponding Charging principles are defined in the TS 32.240 [1]. In the present document, charging support for the 
Transit and Roaming Function (TRF) requisite for Roaming Architecture for Voice over IMS with Local Breakout is 
rendered by presuming collocation or standalone. 

Figure 5. 1 .7 shows an example for possible signalling and media flows in a Roaming Architecture for Voice over IMS 
with Local Breakout. 




Figure 5.1.7: Signalling and media flows in a Roaming Architecture for Voice over IMS with Local Breakout 

(Example) 



5.1 .9 Charging support for Network provicJecJ Location information 

The Network provided Location information (NetLoc) is described in the TS 23.228 [201] and for emergency service 
request using PCC-based solutions for the UE location in TS 23.167 [212]. 

Based on operator policies and the availability of the user location information and/or UE Time Zone from the access 
network, the solution ensures that relevant SIP messages contain the correct or up to date information about the user 
location information, and/or UE Time Zone provided by the access network and currently used by the UE. 

For the 3GPP access networks, the P-CSCF can retrieve user location information and/or UE Time Zone related to the 
access network currently used by the UE using PCC mechanisms, as specified in TS 23.203 [213]. 
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5.1 .9a Charging support for IMS transit scenarios 

The IMS transit network scenarios are described in the TS 23.228 [201] and may require additional functionalities 
provided by the IMS transit functions. When residing in a stand-alone entity, the IMS Transit Functions may apply 
offline charging. Applicable fields for the IMS transit functions are in table 6.3.2.1. 



5.1.10 Charging support for TRF 

In order to support traffic for the Roaming Architecture for Voice over IMS with Local Breakout, IMS Transit 
Functions are enhanced with additional routeing functionality, both combined in a Transit and Roaming Function (TRF) 
and defined in TS 23.228 [201]. Depending on the transit operator configuration, these functions might reside in a 
stand-alone entity or be collocated with an existing IMS Network Element. 

When residing in a stand-alone entity, the TRF may apply offline charging. 

When collocated with an existing IMS Network Element, charging information for the TRF is combined with charging 
information of the corresponding IMS Network Element. Applicable fields are in table 6.3.2.1. 



5.2 IMS Offline Charging Principles 
5.2.1 Basic Principles 

The offline charging functionality is based on the IMS network nodes reporting accounting information upon reception 
of various SIP methods or ISUP messages, as most of the accounting relevant information is contained in these 
messages. This reporting is achieved by sending Diameter Accounting Requests (ACR) [Start, Interim, Stop and Event] 
from the IMS network elements to the CDF. 

The Diameter client uses ACR Start, Interim and Stop in procedures related to successful SIP sessions. It uses ACR 
Events for unsuccessful SIP sessions and for session unrelated procedures. Further details are specified in the tables 
below and in clause 5.2.2. 

It is operator configurable in the nodes for which SIP method or ISUP messages an Accounting Request is sent. 
Table 5.2.1.1 describes all possible ACRs that might be sent fi-om a P-CSCF, I-CSCF, S-CSCF, IBCF, MGCF or 
BGCF. A list of node specific ACRs, along with the AVPs to be included are detailed in TS 32.299 [50]. 

The ACRs to be sent from a MRFC are described in table 5.2.1.2. 

It is configurable for the operators to enable or disable the generation of an ACR message by the IMS node in response 
to a particular "Triggering SIP Method /ISUP Message". 
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Table 5.2.1.1 : Accounting Request Messages Triggered by SIP Methods or ISUP Messages 

for all IMS nodes except for MRFC and AS 



ACR [Start] 


SIP 200 OK acknowledging an initial SIP INVITE 


SIP ACK acknowledging an initial SIP INVITE 


ISUP:ANM (applicable for the MGCF) 


ACR [Interim] 


SIP 200 OK acknowledging a SIP 

RE-INVITE or SIP UPDATE [e.g. change in media components] 


SIP ACK acknowledging an initial SIP INVITE or a SIP RE-INVITE 


Expiration of AVP [Acct-lnterim-lnterval] 


SIP 1xx provisional response, mid-dialog requests, mid-dialog responses and SIP INFO embedding 
Hi \ \ XML Dody (applicable tor the b-ObOh and ibOh). 


lOUr oildiyiliy MoC ^appiiuaUiy iUi lilt; IVIOwr^. 


qip RpcnnnQp (dyy ^yy nr fiyy^ inHiratinn an iinc;iirrpc;qfii| Qip RF-INVITF nr *^IP 1 IPDATF 

Oin PlCoLJUl loC I H-AA, OAA U 1 U AA f, IIIUIOClllllU Cll 1 Ul loUUUCOO IUI OIF 1 1 1 IINVII^UI OIF \Ji 1— \ 1 1 


ACR [Stop] 


oi n [J T ^ 1 1 icood^c ^uvjLi 1 iiuiiiidi diiu ciuii\jiiiicii ocooiui i id i iiii idiitji i Lrdoco^ 


191 IP-RFI /annlirflhip fnr thp IVK^HF^ 

lOUn.riL^L- ^d|J|JllOdLJlC IUI LI IC lvl\Jwny 


ACR [Event] 


QIP OriC\ C^W Qr»knn\A/lorlninn nrtn-coccir^n rolatoH QIP rtioccanoc whiph aro* 
oir ^U\J wr\ dLfiVi luwicuy II iy iiuii ocooiuii icidLcu oir iiicood^uo, wiiiuiidit;. 


QIP MOTIFV 

oil iNV_/ 1 IF T 


qip MFQQAf^F 

oil 1 vl 1 00/\\J 1 


SIP REGISTER 


SIP SUBSCRIBE 


SIP PUBLISH 


SIP 200 OK acknowledging an initial SIP INVITE 


SIP 202 Accepted acknowledging a SIP REFER or any other method 


SIP Final Response 2xx (except SIP 200 OK) 


SIP Final/Redirection Response 3xx 


SIP Final Response (4xx, 5xx or 6xx), indicating an unsuccessful SIP session set-up 


SIP Final Response (4xx, 5xx or 6xx), indicating an unsuccessful session-unrelated procedure 


SIP CANCEL, indicating abortion of a SIP session set-up 


l-CSCF completing a Cx Query that was issued in response to a SIP INVITE 


Table 5.2.1.2: Accounting Request Messages Triggered by SIP Methods for the MRFC 



Diameter 
iUlessage 


Triggering SIP iUlethod 


ACR [Start] 


SIP 200 OK acknowledging an SIP INVITE for initiating a multimedia ad hoc conferencing session 


ACR [Interim] 


SIP ACK acknowledging a SIP INVITE to connect an UE to the conferencing session 


SIP REINVITE (see Note 1) 


SIP BYE (see Note 2) 


Expiration of AVP [Acct-lnterim-lnterval] 


ACR [Stop] 


SIP BYE message (see Note 3) 


SIP CANCEL (see Note 3) 


SIP Final Response with error codes 4xx, 5xx or 6xx indicating termination of an ongoing session 
(see Note 3) 


NOTE 1 : This trigger only applies to a user joining an ongoing conferencing session 
NOTE 2: This trigger only applies to a user leaving an ongoing conferencing session 
NOTE 3: This trigger only applies if this causes the ongoing conferencing session to terminate 
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5.2.2 Diameter Message Flows and Types 

The flows described in the present document specify the charging communications between IMS entities and the 
charging functions for different charging scenarios. The SIP messages and Diameter transactions associated with these 
charging scenarios are shown primarily for general information and to illustrate the charging triggers. They are not 
intended to be exhaustive of all the SIP message flows discussed in TS 24.228 [200] and they depend on the Diameter 
Accounting Requests triggers configured by the operator. 



5.2.2.1 Message Flows - Successful Cases and Scenarios 



5.2.2.1 .1 Session Establishment - Mobile Origination 

The following figure shows the Diameter transactions that are required between CSCF and CDF during session 
establishment originated by a UE. 



Scenario 1 : Successful Session Establishment 



Visited Network 



Home Network 



UE 



1. INVITE 




2. 200 OK 




P-CSCF 



CDF 

(visited) 



1. INVITE 



S-CSCF 



CDF 

(home) 



Service Control 



1. INVITE 



More SIP signalling 



2. 200 OK (Invite) 



5. Accounting Requ 



^. 200 OK (Invite) 



Service Control 



5st [Start] 



Open a P-CSCF CDR 



6. Accounting Answe r 

K 



3. Accounting Requ^t [Start] 




Open a S-CSCF CDR 



4. Accounting Answe: 

K 



More SIP signalling 




SIP Session established 



T" 



Figure 5.2.2.1.1-1 : Message Sequence Chart for Session Establisliment (lUlobile Origination) 



1. 
2. 
3. 



4. 
5. 
6. 



The session is initiated. 

The destination party answers and a final response are received. 
Upon reception of the final response, the S-CSCF sends an Accounting-Request with 
Accounting-Record-Type indicating START_RECORD to record start of a user session and start of 
a media component in the S-CSCF CDR. 

The CDF acknowledges the reception of the data and opens an S-CSCF CDR. 

Same as 3, but for P-CSCF. 

Same as 4, but creating a P-CSCF CDR. 
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Scenario 2: Successful Session Establishment with late SDP Answer (SIP 200 OK triggering ACR) 

The following figure shows the Diameter transactions that are required between CSCF and CDF during session 
establishment originated by a UE. 
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Home Network 



UE 



P-CSCF 



1. INVITE 




CDF 

(visited) 



1. INVITE 



S-CSCF 



CDF 

(home) 



Service Control 



1. INVITE 
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2. 200 OK (SDP ofl er) 



2. 200 OK (SDP offisr) 



5. Accounting Request [Start] 



Open a P-CSCF CDR 



6. Accoimting Answe" 
7. ACK (SDP answ( ^ 7. ACK (SDP ansv er) 



8. Accounting Requei t [Interim] 



Update the P-CSCF CDR 



9. Accounting Answe' 



2. 200OK(SDPoffe ) 



Service Control 



3. Accounting Request [Start] 




Open a S-CSCF CDR 



4. Accounting Answe 



Service Control 



7. ACK (SDP answer) 



10. Accounting Reque st [Interim] 



Update the S-CSCF CDR 



1 1 . Accounting Answ 



Figure 5.2.2.1.1-2: Message Sequence Chart for Session Establishment 
(SIP 200 OK triggering ACR) - Mobile Origination 



4. 
5. 
6. 

7.-11. 



The session is initiated. 

The destination party answers and a response are received. 

Upon reception of the SIP 200 OK, the S-CSCF sends an Accounting-Request with 
Accounting-Record-Type indicating START_RECORD to record start of a user session and start of 
a media component in the S-CSCF CDR. 

The CDF acknowledges the reception of the data and opens an S-CSCF CDR. 

Same as 3, but for P-CSCF. 

Same as 4, but creating a P-CSCF CDR. 

These steps are identical to steps 3. -7. of scenario 2 described in clause 5.2.2.1.3. 
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Scenario 3: Successful Session Establishment with late SDP Answer (SIP ACK triggering ACR) 

The following figure shows the Diameter transactions that are required between CSCF and CDF during session 
establishment originated by a UE. 



Visited Network 



Home Network 




Figure 5.2.2.1.1-3: Message Sequence Chart for Session Estabiishment 
(SiP ACK triggering ACR) - lUlobile Origination 



1. 
2. 

3. 
4. 



5. 
6. 
7. 



The session is initiated. 

The destination party answers and a final response are received. If the final response includes a 
SDP offer only, then the CSCF shall wait for the SIP ACK. 
The SIP ACK including the SDP answer is received. 

Upon reception of the SIP ACK, the P-CSCF sends an Accounting-Request with 
Accounting-Record-Type indicating START_RECORD to record start of a user session and start of 
a media component in the P-CSCF CDR. 

The CDF acknowledges the reception of the data and opens an P-CSCF CDR. 

Same as 4, but for S-CSCF. 

Same as 5, but creating a S-CSCF CDR. 
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5.2.2.1.2 



Session Establishment - Mobile Termination 



The following figure shows the Diameter transactions that are required between CSCF and CDF during a session 
estabUshment that is terminated to a mobile. The I-CSCF is only involved in the INVITE transaction. 
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■* 
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SIP Session estabtished 



Figure 5.2.2.1.2-1 : Message Sequence Chart for Session Establisliment (lUlobile Termination) 



1 . The session is initiated. 

2. Upon completing a Cx query the I-CSCF sends an Accounting Request with the 
Accounting-Record-Type set to EVENT. 

3. The CDF acknowledges the data received and creates an I-CSCF CDR. 

4. The destination party answers and a final response are sent. 

5. - 8. These steps are identical to the corresponding steps described in clause 5.2.2.1.1. 



ETSI 



3GPP TS 32.260 version 11.7.0 Release 11 



25 



ETSI TS 132 260 V1 1.7.0 (2013-04) 



5.2.2.1.3 Mid-Session Procedures 

The following figure shows the Diameter transactions that are required between CSCF and CDF when a UE generates a 
SIP (Re-)INVITE or SIP UPDATE in mid-session, e.g. in order to modify media component(s), or when the hold and 
resume procedure is executed. 

Scenario 1 : Mid-Session Procedures 
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Figure 5.2.2.1.3-1 : Message Sequence Chart for Media Modification 



1 . Modified media information is received from the subscriber. 

2. The destination party acknowledges the media modification. 

3. At modification of a media, the S-CSCF sends Accounting-Request with Accounting-Record-Type 
indicating INTERIM_RECORD to record modification of a media component in the S-CSCF 
CDR. 

4. The CDF acknowledges the reception of the data and updates the S-CSCF CDR. 

5. Same as 3, but for P-CSCF. 

6. Same as 4, updating the P-CSCF CDR. 
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Scenario 2 : Mid-Session Procedures with Late SDP Answer (SIP ACK triggering ACR) 

The following figure shows the Diameter transactions that are required between CSCF and CDF when a UE generates a 
SIP (Re-)INVITE or SIP UPDATE in mid-session, e.g. in order to modify media component(s), or when the hold and 
resume procedure is executed. 
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Update the P-CSCF CDR 
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6. Accounting Reqt^ it [Interim] 



Updatethe S-CSCF CDR 



1 . Accounting Answsr 



SIP Session continues 



Figure 5.2.2.1.3-2: lUlessage Sequence Chart for lUledia lUlodification (SIP ACK triggering ACR) 



1 . The UE generates a SIP Re-INVITE or SIP UPDATE in mid-session. 

2. The destination party repUes with a response including a SDP offer. If the final response includes a 
SDP offer only, then the CSCF shall wait for the SIP ACK. 

3. The SIP ACK including the SDP answer is received. 

4. At modification of a media, the P-CSCF sends Accounting-Request with Accounting-Record-Type 
indicating INTERIM_RECORD to record modification of a media component in the P-CSCF 
CDR. 

5. The CDF acknowledges the reception of the data and updates the P-CSCF CDR. 

6. Same as 4, but for S-CSCF. 

7. Same as 5, updating the S-CSCF CDR. 
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5.2.2.1 .4 Session Release - Mobile Initiated 

The following figure shows the Diameter transactions that are required between CSCF and CDF for a session release 
that is initiated by the UE. 
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,6. 200 OK 
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4. Accounting Reqi^ it [Stop] 



Close the S-CSCF CDR 



^. Accounting 



Answi ;r 



6. 200 OK 



Figure 5.2.2.1.4-1 : iVIessage Sequence Cliart for Session Reiease 



1 . The session is released. 

2. At session termination the P-CSCF sends Accounting-Request with Accounting-Record-Type 
indicating STOP_RECORD to record stop of a session and stop of a media component in the 
P-CSCF CDR. 

3. The CDF acknowledges the reception of the data and closes the P-CSCF CDR. 

4. Same as 2, but for S-CSCF. 

5. Same as 3, closing the S-CSCF CDR. 

6. The release is acknowledged. 
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5.2.2.1.5 



Session-Unrelated Procedures 



The following figure shows the Diameter transactions that are required between CSCF and CDF for session-unrelated 
IMS procedures, i.e. those that relate to the Diameter ACR [Event], as listed in Table 5.2.1.1. 
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CDF 

(visited) 
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t [Event] 



Create S-CSCF CDR 



4. Accounting Answ' ;r 



Figure 5.2.2.1.5-1 : Message Sequence Chart for Session-Unrelated Procedure 



1 . The P-CSCF receives a "SIP Request" (e.g. SUBSCRIBE) from the subscriber. 

2. The "SIP Request" is acknowledged by the "SIP Response" as follows: 

- in the successful case, a 200 OK message is returned; 

- in case of failure an appropriate SIP error message is returned. 

Depending on the used SIP method, there might be additional signalhng between steps 1 and 2. 

3. After the completion of the procedure, the S-CSCF sends Accounting-Request with Accounting- 
Record-Type indicating EVENT_RECORD to record transaction specific information in the 
S-CSCF CDR. 

4. The CDF acknowledges the reception of the data and produces an S-CSCF CDR. 

5. Same as 3, but for P-CSCF. 

6. Same as 4, creating a P-CSCF CDR. 
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5.2.2.1.6 



Session Establishment - PSTN Initiated 



The following figure shows the Diameter transactions that are required between MGCF and CDF during session 
estabUshment initiated from the PSTN side. 
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Session established 



Figure 5.2.2.1.6-1 : Message Sequence Chart for Session Establisliment (PSTN Initiated) 



1 . The session is originated from the PSTN. 

2. The session setup is triggered in the IMS. 

3. The destination party answers and a final response are received. 

4. MGCF forwards an answer message to the PSTN. 

5. Upon reception of the final response, the MGCF sends an Accounting-Request with 
Accounting-Record-Type indicating START_RECORD to record start of a user session and start of 
a media component in the MGCF CDR. 

6. The CDF acknowledges the reception of the data and opens a MGCF CDR. 
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The following figure shows the Diameter transactions that are required between BGCF, MGCF and CDF during session 
estabUshment initiated from the IMS side. 



Home Network 



BGCF 




MGCF 




CDF 




PSTN 




Figure 5.2.2.1.7-1 : Message Sequence Chart for Session Establisliment (IIUIS Initiated) 

1. The session is originated from the IMS. 

2. A session towards PSTN is established. 

3. The destination party answers and an answer message are received. 

4. A final response message is sent to the session originator. 

5. Upon reception of the answer message, the MGCF sends an Accounting-Request with 
Accounting-Record-Type indicating START_RECORD to record start of a user session and start of 
a media component in the MGCF CDR. 

6. The CDF acknowledges the reception of the data and opens a MGCF CDR. 

7. Upon reception of the 200 OK message, the BGCF sends an Accounting-Request with 
Accounting-Record-Type indicating EVENT_RECORD to record start of a user session and start 
of a media component in the BGCF CDR. 

8. The CDF acknowledges the reception of the data and creates a BGCF CDR. 
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5.2.2.1.8 



Session Release - PSTN Initiated 



The following figure shows the Diameter transactions that are required between MGCF and CDF during a PSTN 
initiated session release. 

HameNetvwjk 



MGCF 



CDF 



FSTN 



Session ongoing 



l.REL 



2. BYE 




4. Axounting Request [I >tq)] 



QosetteMGCFCDR 



5. Axounting Ansv^er 



Figure 5.2.2.1.8-1 : Message Sequence Chart for Session Release (PSTN initiated) 



1. The session release is initiated from PSTN. 

2. Session release continues within IMS. 

3. The reception of the release message is acknowledged. 

4. Upon reception of the release message, the MGCF sends an Accounting-Request with 
Accounting-Record-Type indicating STOP_RECORD to record stop of a session in the MGCF 
CDR. 

5. The CDF acknowledges the reception of the data and closes the MGCF CDR. 
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5.2.2.1.9 



Session Release - IMS Initiated 



The following figure shows the Diameter transactions that are required between MGCF and CDF during a IMS initiated 
session release. 
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CDF 



PSTN 



Session ongoing 



1. BYE 



2. REL 



3.RLC 



4. Accounting Request [Stop] 



Close the MGCF CDR 



5. Accounting Answer 



Figure 5.2.2.1.9-1 : Message Sequence Chart for Session Release (IIUIS initiated) 



1. 
2. 

3. 
4. 

5. 



The session release is initiated fi'om the IMS side. 
A release message is sent towards PSTN. 

The acknowledgement of the release message is received from PSTN. 

Upon reception of the BYE message the MGCF sends an Accounting Request with Accounting 
Record Type indicating STOP_RECORD to record stop of a session in the MGCF CDR. 
The CDF acknowledges the reception of the data and closes the MGCF CDR. 
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5.2.2.1.10 



Multi-Party Call 



The following figure shows the estabUshment of an ad hoc conference (multiparty call). An AS (acting as B2BUA) 
performs third party call control with the MRFC, where the S-CSCF is in the signalling path. The Application Server 
that is in control of the ad hoc conference is aware of the MRFC capabihties. Note that only accounting information 
sent from the MRFC is shown in detail in the figure. The SIP messages are for illustrative purpose only. 
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Figure 5.2.2.1.10-1 : iUlessage Sequence Chart for lUluiti-Party Caii Estabiishment in lUIRFC 
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1. Sessions exist between UE-1 and UE-2, and between UE-1 and UE-3. A request is received from 
UE-lfor putting all parties together to a multi -party call. 

2. -3. Request and acknowledgement to initiate multi -party call. MRFC assigns a conference-ID that is 

used by the AS in subsequent interactions with the MRFC in INVITE messages connecting other 
endpoints (see TS 23.228 [201]). Path establishment between AS and MRFC for UE-2. 

4. At start of session establishment the MRFC sends an Accounting-Request with Accounting- 
Record-Type indicating START_RECORD to record start of multi-party call in the MRFC CDR 

5. The CDF acknowledges the reception of the data and creates the MRFC CDR. 'Calling Party 
Address', 'Service Request Time Stamp', 'Service ID' (holding the conference-ID) etc. are included 
in the MRFC CDR 

6-7. Path establishment between UE-2 and AS. Same ICID is used as for the path between AS and 

MRFC for UE-2 (step 2. - 3.). 
8 Acknowledgement of path between AS and MRFC for UE-2. 

9. The MRFC may send an Accounting-Request with Accounting-Record-Type indicating 
INTERIM_RECORD to report that UE-2 has been connected to the multi-party call. 

10. The CDF acknowledges the reception of the data and includes UE-2 in the field 'Application 
Provided Called Parties' of the MRFC CDR. 

1 1 . Acknowledgement of path between AS and UE-2. Now a path between UE-2 and MRFP via AS is 
established. 

12 -13.. Request and acknowledgement to establish path between AS and MRFC for UE-3. 

14. -15. Path establishment between UE-3 and AS. Same ICID is used as for the path between AS and 

MRFC for UE-3 (step 12. - 13.). 

16. Acknowledgement of path between AS and MRFC for UE-3. 

17. The MRFC may send an Accounting-Request with Accounting-Record-Type indicating 
INTERIM_RECORD to report that UE-3 has been connected to the multi-party call. 

18. The CDF acknowledges the reception of the data and includes UE-3 in a new field 'Application 
Provided Called Parties' of the MRFC CDR. 

19. Acknowledgement of path between AS and UE-3. 

20-21. Request and acknowledgement to establish path between AS and MRFC for UE-1. Same ICID is 

used as for the path between UE-1 and AS (step 1.). 
22-23. Request for multi-party conference with UE-2 and UE-3 is acknowledged to UE 1. Implicit 

acknowledgement of path UE-1 to AS. 

24. Acknowledgement of path between AS and MRFC for UE-1 . 

25. The MRFC may send an Accounting-Request with Accounting-Record-Type indicating 
INTERlM_RECORD to report that UE-1 has been connected to the multi-party call. 

26. The CDF acknowledges the reception of the data and includes the field 'Service Delivery Start 
Time Stamp' into the MRFC CDR. 

27 -28. UE-1 acknowledges the multi-party call session establishment. 



NOTE: It is in the responsibility of the AS to terminate the sessions existing at the beginning of the multi-party 

call establishment between UE-1 and UE-2 and between UE-1 and UE-3 (see step 1.) in case of 
successful multi-party call establishment. This is not shown in the diagram above. 
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5.2.2.1.11 



AS Related Procedures - AS Acting as a Redirect Server 



Application servers may support a multitude of services which are not specified in 3GPP standards. Therefore it is not 
possible to standardise charging flows and procedures for those services. However, for all such services, the AS may 
apply either Event Charging, where ACR [Event] messages are generated, or Session Charging, using ACR [Start, Stop 
and Interim]. The following clauses depict one example for each of the two scenarios. The first procedure, AS acting as 
a Redirect Server, depicts the "event" case, while the second procedure, AS acting as a Voice Mail Server, depicts the 
"session" case. 

The following figure shows the case where an Application Server acts as a Redirect Server. In the figure below, UE-I 
sets up a session towards UE-2 but due to Call Forwarding functionality located in the AS, a new number (to UE-3) is 
returned to UE-I. Finally UE-I sets up the session towards UE-3. 



Originating UE-1 
home network 



Terminating UE-2 Home Network 



Terminating UE-3 
home network 



S-CSCF 



I. INVn'H 



AS 



Service control 
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2. 302 MOVED TEMPORARILY 



3. ACK 



4. Accounting Request [Eve it] 



Create an AS CDR 



^. Accounting Answer 



Setting up session towards UE-3 



Figure 5.2.2.1.11-1 : iVIessage Sequence Cliart for AS Acting as a Redirect Server 



1. Sessions initiated by UE-1 towards UE-2. 

2. - 3. Response indicating that session should be redirected towards another number (UE-3). 

4. After successful service execution, the AS sends Accounting-Request with 
Accounting-Record-Type indicating EVENT_RECORD to record service specific information in 
the AS CDR. 

5. The CDF acknowledges the reception of the data and creates the AS CDR. 

6-7. Response indicating that session should be redirected towards another number (UE-3). 

8. Session is initiated by UE-I towards UE-3. 
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5.2.2.1 .12 AS Related Procedures - AS Acting as a Voice Mail Server 

The following figure shows the case where an Application Server acts as a Voice Mail Server. S-CSCF invokes the AS 
acting as Voice Mail Server according to procedure as defined in TS 23.218 [203]. 
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Close the AS CDR 
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< 



Figure 5.2.2.1.12-1 : Message Sequence Chart for AS Acting as a lUlail Server 



1 . AS receives the INVITE from the S-CSCF. 

2. AS acknowledges the initiated Voice Mail session by issuing a 200 OK in response to the 
INVITE. 

3. AS sends Accounting-Request with Accounting-Record-Type indicating START_RECORD to 
record start of a voice mail session. 

4. The CDF acknowledges the reception of the Accounting-Request with Accounting-Record-Type 
indicating START_RECORD and opens a AS CDR. 

5. Voice mail session release is initiated. 

6. Upon reception of release message AS sends an Accounting-Request with Accounting-Record- 
Type indicating STOP_RECORD to record stop of a session in the AS CDR. 

7. The CDF acknowledges the reception of the data and closes the AS CDR. 
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5.2.2.1 .13 AS Related Procedures - AS Acting as a SCC AS 

The charging requirements for IMS service continuity are specified in TS 23.237 [407]. 

Alternative "OneChargingSession"option is also reflected in the different flows description, i.e a single charging 
session fiom SCC AS. 

5.2.2.1 .13.1 UE originating call (PS only or CS only) 

In this flow, Call-ID #1 is for access leg and Call-ID #2 is for remote leg. 
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Figure 5.2.2.1.13.1-1: Message Sequence Chart UE originating call 

1. The sec session is initiated (an INVITE for IMS, a Call Setup for CS). 

2. After processing at CS/PS intermediate nodes, the resulting INVITE is sent to the S-CSCF 

3. The S-CSCF validates the service profile, and invokes any appropriate service logic required for this user. 

4. The S-CSCF forwards the INVITE request message to the SCC AS, according to the service origination logic 

defined by initial Filter Criteria (iFC) in the subscriber profile of the HSS. 

5. The SCC call is anchored at the SCC AS in the home IMS Domain upon reception of the SIP Invite (Call-ID# 1). 
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6-7. The S-CSCF forwards the INVITE request message to the terminating network (Call-ID #2). 

8. The response 200 OK is transmitted to the S-CSCF in the Originating network. 

9. Upon reception of the final response, the S-CSCF in the originating network sends an Accounting-Request with 

Accounting-Record-Type indicating START_RECORD to record SCC call routing and start of a user 
session/media component in the S-CSCF CDR. 

10-1 1. The CDF from the Originating network opens a S-CSCF CDR related to the Remote leg and acknowledges 
the reception of the data. 

12. Same as 8 but for SCC AS (Remote leg) 

13. Same as 9 but for the SCC AS (Remote leg) 

14-15. Same as 10-11 but opening a SCC AS CDR related to the Remote leg 

13-14a-15 Alternatively, when "OneChargingSession", the SCC AS sends an Accounting-Request with Accounting- 
Record-Type indicating START_RECORD to record SCC call routing and start of a user session/media 
components in the SCC AS CDR for the IMS session (ICID) with access leg and remote leg. The CDF opens a 
SCC AS CDR related to the IMS session, and acknowledges the reception of the data. 

16. Same as 8 but for S-CSCF AS (Access leg) 

17. Same as 9 but for the SCC AS (Access leg) . 

18-19. Same as 10-11 but opening a SCC AS CDR (Access leg) . 

.Steps 17 to 19 are not applicable for the "OneChargingSession" option. 
20. Same as 9 but for the S-CSCF (Access leg) 
21-22. Same as 10-11 but opening a S-CSCF CDR (Access leg) 

23. The final response to SIP Invite (Call ID #1) is transmitted. 

24. The session is set up with CS or PS media. 

For IMS Emergency session over PS, the same flow applies in the UE serving Network, between the E-CSCF (instead 
of S-CSCF) and the EATF (Emergency Access Transfer Function, instead of SCC AS), with E-CSCF and EATF CDRs 
opened for access and remote legs. 

EATF (acting as a B2BUA) performs third party call control and is considered as an AS for the charging description. 

5.2.2.1.13.2 UE originating call (PS and CS combined origination) 

In this flow, Call-ID #1 is for PS access leg, Call-ID #1' for CS access leg and CaU-ID #2 for remote leg. 
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Figure 5.2.2.1.13.2-1: Message Sequence Chart UE originating call 

1. UE-1 wants to initiate a multimedia session with UE-2 with speech components carried on CS bearers and non- 

speech components carried on PS bearers. Therefore the muhimedia session is split into two parts, each one 
corresponding to a separate access leg. UE-1 initiates the estabhshment of the first access leg by sending an 
LNVITE request with non-speech media components. The EWTTE contains STI information indicating that a 
second access leg (with the speech component) will be originated from the CS domain. 

2. The S-CSCF executes any service logic as appropriate. 

3. The S-CSCF sends the INVITE to the SCC AS. The SCC AS identifies that this access leg has to be correlated to 

a subsequent access leg based on the STI information in the INVITE. 

4. UE-1 request to set up call with CS bearer. The called party number is set to an identifier such as a PSl DN, 

which is used to indicate to the SCC AS that this access leg is to be combined with a PS leg. The DN is either 
statically coirfigured on the UE or assigned to the UE by the network upon IMS Registration. 

5. After processing at ICS/Inter working nodes, the resulting INVITE is sent to the S-CSCF. 

6. The S-CSCF executes any service logic as appropriate. 

7. The S-CSCF sends the INVITE to the SCC AS. The SCC AS identifies that this CS leg has to be correlated to a 

PS leg based on the iFC in the EWITE. 

8. After the SCC AS receives both the INVITE requests in step 3 and in step 7, the SCC AS identifies that they are 

part of the same multimedia session and combines the two access legs of the session by checking the caller's 
identity and anchor the combined session. 

9-10. The SCC AS sends INVITE to the remote end point for combined session estabhshment. 

11. The 200 OK response is transmitted to the S-CSCF in the Originating network. 

12. Upon reception of the final response, the S-CSCF in the originating network sends an Accounting-Request with 
Accounting-Record-Type indicating START_RECORD to record SCC call routing and start of a user 
session/media component in the S-CSCF CDR. 

13-14. The CDF from the Originating network opens an S-CSCF CDR related to the Remote leg and acknowledges 
the reception of the data. 

15. Same as 11 but for SCC AS (Remote leg) 

16. Same as 12 but for the SCC AS (Remote leg) 

17-18. Same as 13-14 but opening a SCC AS CDR related to the Remote leg 

16-17a-18 Alternatively, when "OneChargingSession", the SCC AS sends an Accounting-Request with Accounting- 
Record-Type indicating START_RECORD to record start of the SCC AS CDR for the IMS session (ICID) with 
the CS access leg, PS access leg and the Remote leg. The CDF opens a SCC AS CDR related to the IMS session, 
and acknowledges the reception of the data. 

19. Same as 1 1 but for S-CSCF (Access leg) 

20. Same as 12 but for the SCC AS (Access leg) 

21-22. Same as 13-14 but opening a SCC AS CDR for the PS access leg. 

Steps 20 to 22 are not apphcable for the "OneChargingSession" option. 
23. Same as 12 but for the S-CSCF (Access leg) 

24-25. Same as 13-14 but opening a S-CSCF CDR for the PS access leg. 

26. Same as 1 1 but for S-CSCF AS (Access leg). 

27. Same as 12 but for the SCC AS (Access leg). 
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28-29. Same as 13-14 but opening a SCC AS CDR for the CS access leg. 

Steps 27 to 29 are not applicable for the "OneChargingSession" option. 
29. Same as 12 but for the S-CSCF (Access leg) 
30-31. Same as 13-14 but opening a S-CSCF CDR for the CS access leg. 

32. The final 200 OK response is sent to the UE #1 

33. The 200 OK response is sent to the ICS intermediate nodes. 

34. The completion of the CS call bearer is done. 

5.2.2.1.13.3 UE terminating call (PS only or CS only) 

In this flow, Call-ID #1 is for PS access leg and Call-ID #2 for remote leg. 
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Figure 5.2.2.1.13.3-1: iVIessage Sequence Chiart UE terminating call 

1. The sec session is initiated by UE #2 sending an INVITE to S-CSCF. 

2. The S-CSCF validates the service profile, and invokes any appropriate service logic required for this user. 

3. The S-CSCF forwards the INVITE request message to the SCC AS, according to the service origination logic 

defined by initial Filter Criteria (iFC) in the subscriber profile of the HSS. 



4. The SCC call is anchored at the SCC AS in the home IMS Domain upon reception of the SIP Invite (Call ID #2). 
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5-6-7. The S-CSCF forwards the INVITE request message to the terminating network (Call ID #1). After processing 
at CS/PS intermediate nodes, the resulting message is sent to UE #1. 

8. The response 200 OK is transmitted to CS/PS intermediate nodes. 

9. After processing at CS/PS intermediate nodes, the 200 OK message is sent to S-CSCF. 

10. Upon reception of the final response, the S-CSCF in the originating network sends an Accounting-Request with 
Accounting-Record-Type indicating START_RECORD to record SCC call routing and start of a user 
session/media component in the S-CSCF CDR. 

1 1-12. The CDF from the Originating network opens an S-CSCF CDR related to the Access leg and acknowledges 
the reception of the data. 

13. Same as 9 but for SCC AS (Access leg) 

14. Same as 10 but for the SCC AS (Access leg) 

15-16. Same as 11-12 but opening a SCC AS CDR related to the Access leg 

14-15a-16 Alternatively, when "OneChargingSession", the SCC AS sends an Accounting-Request with Accounting- 
Record-Type indicating START_RECORD to record SCC call routing and start of a user session/media 
components in the SCC AS CDR for the IMS session (ICID) with access leg and remote leg. The CDF opens a 
SCC AS CDR related to the IMS session and acknowledges the reception of the data. 

17. Same as 9 but for SCC AS (Remote leg) 

18. Same as 10 but for the SCC AS (Remote leg) . 

19-20. Same as 11-12 but opening a SCC AS CDR (Remote leg). 

Steps 18 to 20 are not appUcable for the "OneChargingSession" option. 
21. Same as 10 but for the S-CSCF (Remote leg) 
22-23. Same as 11-12 but opening a S-CSCF CDR (Remote leg) 
24. The final response to SIP Invite (Call ID #2) is transmitted. 

5.2.2.1 .13.4 UE terminating call (PS and CS combined origination) 

In this flow, Call-ID #1 is for PS access leg, Call-ID #1' for CS access leg and CaU-ID #2 for remote leg. 
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Figure 5.2.2.1.13.4-1: Message Sequence Chart UE terminating call 
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1. UE-2 sends INVITE to UE-1 to establish a session with both speech and non-speech components. 

2. The S-CSCF executes any service logic as appropriate. 

3. The S-CSCF sends the INVITE to the SCC AS. The SCC AS identifies that this access leg has to be correlated to 

a subsequent access leg based on the ST information in the INVITE. 

4. The session is anchored at the SCC AS. Based on operator policy and on information indicating that UE-1 is 

accessible over both the PS and CS domains, the SCC AS decides to split the session over PS and CS domains. 
This behaviour is similar to the behaviour of a CSI AS specified in TS 23.279. 

5-6. The SCC AS sends INVITE for the non-speech part of the session. The INVITE contains STI information 
indicating that the speech component will be established from the CS domain. 

7-8. The SCC AS sends INVITE for the speech part of the session and the S-CSCF forwards the EWITE to the 
ICS/Interworking nodes. 

9. The ICS/Interworking nodes set up call to UE-1 with CS bearer. 

10-18. A 200 OK response is sent to the S-CSCF. The speech and non-speech part of the session is established. 

11. Upon reception of the response, the S-CSCF in the originating network sends an Accounting-Request with 
Accounting-Record-Type indicating START_RECORD to record SCC call routing and start of a user 
session/media component in the S-CSCF CDR. 

12-13. The CDF from the Originating network opens an S-CSCF CDR related to the PS Access leg and 
acknowledges the reception of the data. 

14. Same as 10 but for SCC AS (Access leg) 

15. Same as 11 but for the SCC AS (Access leg) 

16-17. Same as 12-13 but opening a SCC AS CDR related to the PS Access leg. 

15-16a-17 Alternatively, when "OneChargingSession", the SCC AS sends &n Accounting-Request with 
Accounting-Record-Type indicating START_RECORD to record start of the SCC AS CDR for the IMS 
session (ICID) with the PS access leg and the Remote leg. The CDF opens the SCC AS CDR related to the 
IMS session and acknowledges the reception of the data. 

19. Upon reception of the response, the S-CSCF in the originating network sends w Accounting-Request with 
Accounting-Record-Type indicating START_RECORD to record SCC call routing and start of a user 
session/media component in the S-CSCF CDR. 

20-21. The CDF from the Originating network opens an S-CSCF CDR related to the CS Access leg and 
acknowledges the reception of the data. 

22. Same as 10 but for SCC AS (Access leg) 

23. Same as 11 but for the SCC AS (Access leg) 

24-25. Same as 12-13 but opening a SCC AS CDR related to the CS Access leg. 

23-24a-25 Alternatively, when "OneChargingSession", the SCC AS sends w Accounting-Request W\\h Accounting- 
Record-Type indicating 1NTER1M_REC0RD to record modification of the SCC AS CDR for the IMS session 
(ICID) with the CS access leg. The CDF updates the SCC AS CDR related to the IMS session and acknowledges 
the reception of the data. 

26. Same as 10 but for S-CSCF (Remote leg) 

27. Same as 1 1 but for the SCC AS (Remote leg) 

28-29. Same as 12-13 but opening a SCC AS CDR for the Remote leg. 

Steps 27 to 29 are not apphcable for the "OneChargingSession" option. 
30. Same as 11 but for the S-CSCF (Remote leg) 
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31-32. Same as 12-13 but opening a S-CSCF CDR for the Remote leg. 
33. The 200 OK response is sent to the UE #2. 

5.2.2.1 .13.5 Session transfer from PS to CS 

In this flow, Call-ID #1 is for PS access leg, Call-ID #1' for CS access leg and Call-ID #2 for remote leg. 
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Figure 5.2.2.1.13.5-1 : Message Sequence Chart UE Domain Transfer PS access to CS access 

The user is engaged in an active multimedia session with UE-2 viaPS access. 

1-2. UE-1 originates a multimedia call in the CS domain including the STN infonnation to request the real time 
media transfer to CS access. 
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3. The ICS intermediate Nodes convert the request into IMS SIP format and then forward the converted request to 

the S-CSCF. 

4. The S-CSCF invokes the SCC Application as the first Apphcation Server of any Application Servers that need to 

remain in the path of the call after session transfer. 

5. The S-CSCF forwards the INVITE to the SCC Apphcation over the ISC interface. 

6 The SCC AS analyses the INVITE to derive that the INVITE is a request to transfer a multimedia session with 
video and voice media components to the PS domain.. 

7-9. The SCC AS sends a re-INVITE to the Remote UE to update the media components of the previous dialog. 
Remote UE answers by a 200 OK message. 

10-12. At Remote Leg update the S-CSCF in the originating network sends Accounting-Request with Accounting- 
Record-Type indicating INTERIM_RECORD to record update of a session in the S-CSCF CDR. 

13. The S-CSCF answers to the INVITE message in 7. 

14-16. At Remote Leg update the SCC AS sends Accounting-Request with Accounting-Record-Type indicating 
INTERIM_RECORD to record update of a session in the SCC AS CDR. 

14-15a-16. Alternatively, when "OneChargingSession", the SCC AS sends an Accounting-Request with Accounting- 
Record-Type indicating INTERIM_RECORD to record modification of SCC AS CDR for the IMS session 
(ICID) with the new legs configuration (Remote leg and new CS access leg).The CDF updates the SCC AS CDR 
related to the IMS session and acknowledges the reception of the data. 

17. The SCC AS answers to the INVITE message in 5.18-20. Upon generation of the 200 OK response, the SCC AS 
in the home IMS of the originating SCC user sends an Accounting-Request with Accounting-Record-Type 
indicating START_RECORD to record start of a user session in the SCC AS-CDR for Call-ID #1'. The CDF 
from the originating network opens an AS CDR and acknowledges the reception of the data. 

Steps 18 to 20 are not applicable for the "OneChargingSession" option. 



21-23. Upon generation of the 200 OK response, the S-CSCF in the home IMS of the originating SCC user sends an 
Accounting-Request with Accounting-Record-Type indicating START_RECORD to record start of a user 
session in the S-CSCF-CDR for Call-ID #1'.. The CDF from the originating network opens an S-CSCF CDR and 
acknowledges the reception of the data. 

24. The 200 OK response is sent by the S-CSCF. 

25. The 200 OK response is converted by the ICS/Interworking nodes in CS format. 
26-28. The UE #1 acknowledges by sending an ACK message to the SCC AS. 



29-31. The SCC Application sends BYE request to release the old access leg. 

32-34. At session termination the SCC AS sends Accounting-Request with Accounting-Record-Type indicating 
STOP_RECORD to record stop of a session and stop of a media component in the SCC AS CDR. This CDR 
may be generated with special handling. One example of special handUng is to zero rate the IMS resource usage 
for the Access leg establishment. 

Steps 32 to 34 are not apphcable for the "OneChargingSession" option. 

35-37. The S-CSCF in the originating network sends Accounting-Request with Accounting-Record-Type indicating 
STOP_RECORD for closing the S-CSCF CDR related to the initial Access leg. This CDR may be generated 
with special handhng. One example of special handhng is to zero rate the IMS resource usage for Access leg 
estabhshment. This can be performed using the correlation mechanism with the SCC AS CDR for Access leg. 

38-40. The UE-1 acknowledges the release of old access leg. 
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5.2.2.1 .13.6 Session transfer from CS to PS 

In this flow, Call-ro #1 is for PS access leg, Call-ID #1' for CS access leg and Call-ID #2 for remote leg. 
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Figure 5.2.2.1.13.6-1 : lUlessage Sequence Chart UE Domain Transfer CS access to PS access 
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The user is engaged in an active multimedia session with UE-2 via CS access. 

1. UE-1 originates a call in the PS domain including the STI to request the multimedia session transfer to PS access 

in conjunction with CS access. 

2. The session estabhshment request is routed to the S-CSCF by the P-CSCF. 

3. The S-CSCF invokes the SCC Application as the first AppUcation Server of any AppUcation Servers that need to 

remain in the path of the call after session transfer. 

4. The S-CSCF forwards the INVITE to the SCC Apphcation over the ISC interface. 

5. The SCC Application analyses the INVITE to derive that the INVITE is a request to transfer a multimedia session 

with video and voice media components to the PS domain. 

6-8. The SCC AS sends a re-INVITE to the Remote UE to update the media components of the previous dialog. 
Remote UE answers by a 200 OK message. 

9-11. At Access Leg update the S-CSCF in the originating network sends Accounting-Request with Accounting- 
Record-Type indicating 04TERIM_REC0RD to record update of a session in the S-CSCF CDR. 

12. The S-CSCF answers to the INVITE message in 6. 

13-15. At Access Leg update the SCC AS sends Accounting-Request with Accounting-Record-Type indicating 
E^ERIM_RECORD to record update of a session in the SCC AS CDR. 

13-14a-15. Alternatively, when "OneChargingSession", the SCC AS sends an Accounting-Request with Accounting- 
Record-Type indicating INTERIM_RECORD to record modification of SCC AS CDR for tiie IMS session 
(ICID) with the new legs configuration (Remote leg and new PS access leg).The CDF updates the SCC AS CDR 
related to the IMS session and acknowledges the reception of the data. 

16. The SCC AS answers to the INVITE message in 4. 

17-19. Upon generation of the final response, the SCC AS in the home IMS of the originating SCC user sends an 
Accounting-Request with Accounting-Record-Type indicating START_RECORD to record start of a user 
session in the SCC AS-CDR. The CDF from the originating network opens an AS CDR and acknowledges the 
reception of the data. 

Steps 17 to 19 are not appUcable for the "OneChargingSession" option. 

20-22. Upon generation of the final response, the S-CSCF in the home IMS of the originating SCC user sends an 
Accounting-Request with Accounting-Record-Type indicating START_RECORD to record start of a user 
session in the S-CSCF-CDR. The CDF from the originating network opens an S-CSCF CDR and acknowledges 
the reception of the data. 

23. The S-CSCF answers to the INVITE message in 2. 

24-25. The 200 OK is acknowledged. 

26-28. The SCC Application sends BYE request to release the old access leg. 29-31 The SCC AS sends Accounting- 
Request with Accounting-Record-Type indicating STOP_RECORD for closing the SCC AS CDR related to the 
original Access leg. The CDF updates the SCC AS CDR related to the IMS session and acknowledges the 
reception of the data 

Steps 29 to 31 are not apphcable for the "OneChargingSession" option. 

32-34. The S-CSCF sends Accounting-Request with Accounting-Record-Type indicating STOP_RECORD for 
closing the S-CSCF CDR related to the original Access leg. This CDR may be generated with special handling. 
One example of special handUng is to zero rate the IMS resource usage for Access leg establishment. This can be 
performed using the correlation mechanism with the SCC AS CDR for Access leg. 

35-37 The UE-1 acknowledges the release of old access leg. 
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In this flow, Call-ID #1 is for PS2 access leg, CaU-ID #1' for PSl access leg, Call-ID #1" for CS access leg and Call-ID 
#2 for remote leg. 
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Figure 5.2.2.1.13.7-1 : Message Sequence Chart UE Domain Transfer PS2 access to PS1 and CS 

access. 

I- 2. UE-1 originates a call in the PSl domain including the STI to request the multimedia session transfer to PSl 

access in conjunction with CS access. 

3. The session establishment request is routed to the S-CSCF by the P-CSCF. 

4. The S-CSCF invokes the SCC Application as the first Application Server of any Application Servers that need to 

remain in the path of the call after session transfer. 

5. The S-CSCF forwards the INVITE to the SCC AppUcation over the ISC interface. 

6. The SCC Application analyses the STI and decides to wait for the session transfer request in CS access. 

7. UE-1 origins a CS call including STN to indicate to the network that this is a session transfer request. 

8. The ICS intermediate Nodes convert the request into IMS SIP format and then forward the converted request to 

the S-CSCF. 

9. The S-CSCF forwards the EWITE to the SCC AppUcation over the ISC interface. 

10. The SCC Application correlates the two requests and decides to update the Remote leg. 

II- 13. The SCC AS sends a re-INVITE to the Remote UE to modify the media components of the existing dialog 
identified in the REFER request. The re-lNVlTE proposes new SDP parameters based on the parameters 
received from UE-2 in step 6 When the Remote UE receives the new media parameters, it returns an answer and 
starts the reception/transmission of these media components. 

14-16. At Access Leg update the S-CSCF in the originating network sends Accounting-Request with Accounting- 
Record-Type indicating INTERIM_RECORD to record update of a session in the S-CSCF CDR. 

17. The S-CSCF answers to the INVITE message in 11. 

18-20. At Access Leg update the SCC AS sends Accounting-Request with Accounting-Record-Type indicating 
INTERIM_RECORD to record update of a session in the SCC AS CDR 

18-19a-20. Alternatively, when "OneChargingSession", the SCC AS sends an Accounting-Request with Accounting- 
Record-Type indicating lNTERIM_RECORD to record modification of SCC AS CDR for the IMS session 
(ICID) with the new PS access leg, new CS access leg and Remote leg. The CDF updates the SCC AS CDR 
related to the IMS session and acknowledges the reception of the data.. 

21. The S-CSCF answers to the INVITE message in 5. 

22-24. Upon generation of the final response, the SCC AS in the home IMS of the originating SCC user sends an 
Accounting-Request with Accounting-Record-Type indicating START_RECORD to record start of a user 
session in the SCC AS-CDR for Call-ID #1' . The CDF from the originating network opens an AS CDR and 
acknowledges the reception of the data. 

Steps 22 to 24 are not applicable for the "OneChargingSession" option. 

25-27. Upon generation of the final response, the S-CSCF in the home IMS of the originating SCC user sends an 
Accounting-Request with Accounting-Record-Type indicating START_RECORD to record start of a user 
session in the S-CSCF-CDR for Call-ID #1'. The CDF from the originating network opens an S-CSCF CDR and 
acknowledges the reception of the data. 

28-29. The S-CSCF accepts session continuity message from the Remote UE by sending a 200 OK response (for the 
PSl INVITE message). 

30-32. UE-1 sends an ACK response to the SCC AS. 

33. The S-CSCF answers to the INVITE message in 9. 
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34-36. Upon generation of the final response, the SCC AS in the home IMS of the originating SCC user sends an 
Accounting-Request with Accounting-Record-Type indicating START_RECORD to record start of a user 
session in the SCC AS-CDR for Call-ID #1". The CDF from the originating network opens an AS CDR and 
acknowledges the reception of the data. 

Steps 34 to 36 are not applicable for the "OneChargingSession" option. 

37-39. Upon generation of the final response, the S-CSCF in the home IMS of the originating SCC user sends an 
Accounting-Request with Accounting-Record-Type indicating START_RECORD to record start of a user 
session in the S-CSCF-CDR for Call-ID #1". The CDF from the originating network opens an S-CSCF CDR and 
acknowledges the reception of the data. 

40-41. The S-CSCF accepts session continuity message from the Remote UE by sending a 200 OK response (for the 
CS INVITE message). 

42-44. UE-1 sends an ACK response to the S-CSCF. 

45. Once acknowledgment has been received for the both leg, the ACK message is sent to the remote UE. 
46-48. The SCC Application initiates to release the old access leg 

49-51. The SCC AS sends Accounting-Request with Accounting-Record-Type indicating STOP_RECORD for 
closing the SCC AS CDR related to the original Access leg. The CDF updates the SCC AS CDR related to the 

IMS session and acknowledges the reception of the data 

Steps 49 to 5 1 are not appUcable for the "OneChargingSession" option. 

52-54. The S-CSCF sends Accounting-Request with Accounting-Record-Type indicating STOP_RECORD for 
closing the S-CSCF CDR related to the original Access leg. This CDR may be generated with special handling. 
One example of special handling is to zero rate the IMS resource usage for Access leg establishment. This can be 
performed using the correlation mechanism with the SCC AS CDR for Access leg. 

55-56. The UE answers by a 200 OK message to the S-CSCF. 

57. The S-CSCF sends a 200 OK message to the SCC AS the releasing of the old access leg. 
5.2.2.1.13.8 Session transfer from (CS-i-PS) to PS 

In this flow, Call-ID #1 is for PS2 access leg, Call-ID #1' for CS access leg, Call-ID #1" for PSl access leg and Call-ID 
#2 for remote leg. 
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Figure 5.2.2.1.13.8-1 : Message Sequence Chart UE Domain Transfer PS2 access and CS access 

to PS1 access 
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1-2. UE-1 originates a call in the PSl domain including the STI to request the multimedia session transfer to PSl 

access. 

3. The session establishment request is routed to the S-CSCF by the P-CSCF. 

4. The S-CSCF invokes the SCC Application as the first Apphcation Server of any Apphcation Servers that need to 

remain in the path of the call after session transfer. 

5. The S-CSCF forwards die INVITE to die SCC Apphcation over the ISC interface. 

6. The SCC Application analyses the STI and decides to update the Remote leg. 

7-9. The SCC AS sends a re -INVITE to the Remote UE to modify the media components of the existing dialog 
identified in the REFER request. The re-lNVlTE proposes new SDP parameters based on the parameters 
received from UE-2 in step 6 When the Remote UE receives the new media parameters, it returns an answer and 
starts the reception/transmission of these media components. 

10-12. At Access Leg update the S-CSCF in the originating network sends Accounting-Request with Accounting- 
Record-Type indicating 1NTER1M_REC0RD to record update of a session in the S-CSCF CDR. 

13. The S-CSCF answers to the INVITE message in 7. 

14-16. At Access Leg update the SCC AS sends Accounting-Request with Accounting-Record-Type indicating 
1NTER1M_REC0RD to record update of a session in the SCC AS CDR 

14-15a-16. Alternatively, when "OneChargingSession", the SCC AS sends an Accounting-Request with Accounting- 
Record-Type indicating INTERIM_RECORD to record modification of SCC AS CDR for the IMS session 
(ICID) with remote leg and new PS access leg. The CDF updates the SCC AS CDR related to the IMS session 
and acknowledges the reception of the data.. 

17. The SCC AS answers to the INVITE message in 5. 

18-20. Upon generation of the final response, the SCC AS in the home IMS of the originating SCC user sends an 
Accounting-Request with Accounting-Record-Type indicating START_RECORD to record start of a user 
session in the SCC AS-CDR. The CDF from the originating network opens an AS CDR and acknowledges the 
reception of the data 

Steps 18 to 19 are not applicable for the "OneChargingSession" option. 

21-23. Upon generation of the final response, the S-CSCF in the home IMS of the originating SCC user sends an 
Accounting-Request with Accounting-Record-Type indicating START_RECORD to record start of a user 
session in the S-CSCF-CDR. The CDF from the originating network opens an S-CSCF CDR and acknowledges 
the reception of the data. 

24. The S-CSCF answers to the INVITE message in 3. 

25 The 200 OK message is sent to UE #1. 

26-30. UE-1 sends an ACK response to the S-CSCF. The ACK message is sent to the remote UE. 

31-33. The source Access Leg 2(which is one of the Access Legs previously established over PS2) is released by the 
SCC Application in this example, however the UE-1 may initiate to release the source Access Leg 2. 

34-36. The SCC AS sends Accounting-Request with Accounting-Record-Type indicating STOP_RECORD for 
closing the SCC AS CDR related to the original Access leg. The CDF updates the SCC AS CDR related to the 

IMS session and acknowledges the reception of the data 

Steps 34 to 36 are not applicable for the "OneChargingSession" option. 

37-39. The S-CSCF sends Accounting-Request with Accounting-Record-Type indicating STOP_RECORD for 
closing the S-CSCF CDR related to the original PS Access leg. This CDR may be generated with special 
handling. One example of special handling is to zero rate the IMS resource usage for Access leg estabhshment. 
This can be performed using the correlation mechanism with the SCC AS CDR for PS Access leg. 

40-42. The UE-1 answers to the BYE message in 33. 
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43-45. The SCC Application initiates to release the old access leg via CS access in this example, however the UE-1 

may initiate to release the source Access Leg. 

46-48. The SCC AS sends Accounting-Request with Accounting-Record-Type indicating STOP_RECORD for 
closing the SCC AS CDR related to the original CS Access leg. The CDF updates the SCC AS CDR related to 
the IMS session and acknowledges the reception of the data 

Steps 46 to 48 are not applicable for the "OneChargingSession" option. 

49-51. The S-CSCF sends Accounting-Request with Accounting-Record-Type indicating STOP_RECORD for 
closing the S-CSCF CDR related to the original CS Access leg. This CDR may be generated with special 
handling. One example of special handhng is to zero rate the IMS resource usage for Access leg estabUshment. 
This can be performed using the correlation mechanism with the SCC AS CDR for CS Access leg. 



52-54. The UE-1 answers to the BYE message in 43. 
5.2.2.1 .13.9 IMS Emergency Session transfer from PS to CS 

In this flow, Call-ID #1 is for PS access leg, Call-ID #1' for CS access leg and CaU-ID #2 for remote leg. 
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Figure 5.2.2.1.13.9-1 : lUlessage Sequence Chart UE Domain Transfer PS access to CS access for liUIS 

emergency session. 

1-2. UE originates an IMS emergency session transfer towards EATF via I-CSCF. 

3. From the received INVITE analysis, the EATF derives a request for transfer of the existing IMS emergency 

session to the CS domain, and proceeds with switch of access leg communicating with the Remote Leg from Old 
PS Access Leg to new CS Access Leg. 

4-5. The EATF performs the Remote Leg update by sending the SIP re-INVITE request towards the remote end vie 
E-CSCF. 
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6-8 Upon receipt of the 200 OK response, the E-CSCF sends an Accounting-Request with Accounting-Record-Type 
indicating INTERIM_RECORD to record update of the E-CSCF CDR for remote leg Call-ID #2. 

9-11 Upon receipt of the 200 OK response, the EATF sends an Accounting-Request with Accounting-Record-Type 
indicating START_RECORD to record start of an EATF CDR for new access leg Call-ID #1'. Alternatively, 
when "OneChargingSession", the EATF sends an Accounting-Request with Accounting-Record-Type indicating 
INTERIM_RECORD to record modification of EATF CDR for the IMS session (ICID) with new CS access leg. 
The CDF updates the EATR CDR related to the IMS session and acknowledges the reception of the data. 

12-14 Upon receipt of the 200 OK response, the I-CSCF sends an Accounting-Request with Accounting-Record- 
Type indicating EVENT_RECORD to create an I-CSCF CDR for new access leg Call-ID #1'. 

15. The 200 OK response is sent towards the UE via ICS/Interworking nodes. 

16-17 Upon release of old access leg, the EATF sends an Accounting-Request with Accounting-Record-Type 
indicating STOP_RECORD to record stop of the EATF CDR for old access leg CaU-ID #1. 

Steps 16 to 17 are not appUcable for the "OneChargingSession" option. 



18-19 Upon release of old access leg, the E-CSCF sends an Accounting-Request with Accounting-Record-Type 
indicating STOP_RECORD to record stop of the E-CSCF CDR for old access leg Call-ID #1. 



EATF (acting as a B2BUA) performs third party call control and is considered as an AS for the charging description. 
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5.2.2.1 .14 Initiating Alternate Charged Party Call 

The following figure shows the case where a call with an alternate charged party is successfully initiated. 
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Figure5.2.2.1.14-1: Successful Initiation of Alternate Party Charging 

1 . The AS receives a SIP Invite. 

2. After determining that Alternate Charged Party is supported, the AS initiates an Invite with an "Alternate Party Identity" for charging. The 
method for determination of the alternate charged party includes accessing subscriber data and doing a security assessment. 

3. The terminating side issues a 200 OK (Answer), to AS. 

4. The AS sends a 200 OK. 

5 . The AS sends an accounting request to the CDF. 

6. The CDF opens a CDR with the Subscription-ID for the Alternate Charged Party and sends an accounting answer to the AS. 

7. The session is estabhshed. 
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5.2.2.1.15 



Session Establishment via IBCF to S-CSCF - IMS Initiated 



The following figure shows the Diameter transactions that are required between IBCF, S-CSCF and CDF in each IMS 
network during session estabUshment. 
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Figure 5.2.2.1.15-1 : Message Sequence Chart for IMS Initiated Session Establishment via IBCF 



1 . The session is originated in Home IMS A, and an INVITE is sent through to Home IMS B via 
IBCFs. 

2. All of the IMS network entities respond with successful 200 OK to the Invite. 

3. Upon reception of the answer message, the IBCFs send an Accounting-Request with 
Accounting-Record-Type to the CDF in each IMS indicating START_RECORD to record start of 
a user session and start of a media component in the IBCF and CDRs. 

4 The CDF in each IMS acknowledges the reception of the data and opens an IBCF CDR 

5. Upon reception of the answer message, the S-CSCFs send an Accounting-Request with 

Accounting-Record-Type to the CDF in each IMS indicating START_RECORD to record start of 

a user session and start of a media component in the and S-CSCF. 
6 The CDF in each IMS acknowledges the reception of the data and opens an S-CSCF CDR. 

7. The session is established. 
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5.2.2.1.16 AS Related Procedures - AS Acting as a MMTel AS. 

For details on charging at AS acting as an MMTel server, providing service such as CDIV, CONF and TIP/TIR, see the 
TS 32.275 [35]. 

5.2.2.1 .17 Session Establishment via IBCF to a third party AS providing tariff information in 
real time (RTTI) 

The following figure shows the Diameter transactions that are required between S-CSCF, IBCF and CDF, in each IMS 
network, during session establishment. It represents a charging interconnect scenario where the third party AS (located 
in another network) provides e.g. value-added service and real time tariff information according to TS 29.658 [206]. 

Editor's Note: The interconnect scenario between IMS network and PSTN (involving MGCF rather than IBCF) is 
FFS. 
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Figure 5.2.2.1.17-1 : Message Sequence Chart for IMS Initiated Session Establishment with a 3^' party 

AS providing real-time tariff information (RTTI) 



1 . The session is initiated. 

2. The destination (third party AS) answers with successful 200OK to the INVITE. The third party 
AS includes a real time tariff information within the 200OK response. 

3. Upon reception of the final response, the S-CSCF sends an Accounting-Request with 
Accounting-Record-Type indicating START_RECORD to record start of a user session and start of 
a media component in the S-CSCF. 

4 The CDF in each IMS network acknowledges the reception of the data and opens an S-CSCF 

CDR. 

5. Upon reception of the 200 OK message, the IBCFs send an Accounting-Request with 

Accounting-Record-Type to the CDF in each IMS indicating START_RECORD to record start of 
a user session and start of a media component in the IBCF. 
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5.2.2.1.18 



The CDF in each IMS acknowledges the reception of the data and opens an IBCF CDR. 
Third party AS providing tariff information in real time (RTTI) during tine session 



The following figure shows the Diameter transactions that are required between S-CSCF, IBCF and CDF, in each IMS 
network, when a third party AS (located in another network) involved in the session provides e.g. value-added service 
and real time tariff information according to TS 29.658 [206] during the session. 
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Figure 5.2.2.1.18-1 : Message Sequence Chart for third party AS providing tariff information in real 

time (RTTI) during the session 



1 . The third party AS includes an RTTI within a SIP INFO and sends the message to the originating 
party. 

2. Upon reception of the INFO embedding RTTI, the S-CSCF sends an Accounting-Request with 
Accounting-Record-Type indicating INTERIM_RECORD to record tariff information in the CDR. 

3. The CDF acknowledges the reception of the data and updates the S-CSCF CDR. 

4 Upon reception of the INFO embedding RTTI, the IBCF sends an Accounting-Request with 

Accounting-Record-Type indicating INTERIM_RECORD to record tariff information in the CDR. 

5. The CDF acknowledges the reception of the data and updates the IBCF-CDR. 

6. Upon reception of the INFO embedding RTTI, the IBCF sends an Accounting-Request with 
Accounting-Record-Type indicating INTERIM_RECORD to record tariff information in the CDR. 

7. The CDF acknowledges the reception of the data and updates the IBCF-CDR. 

8. Upon reception of the INFO embedding RTTI, the S-CSCF sends an Accounting-Request with 
Accounting-Record-Type indicating 1NTER1M_REC0RD to record tariff information in the CDR. 

9. The CDF acknowledges the reception of the data and updates the S-CSCF CDR. 
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5.2.2.1 .19 Support of Optimal Media Routing (OMR) 

Optimal Media Routing (OMR) relies on IMS-ALG function enhancement, used by some IMS Nodes as described in 
TS 23.228 [201] Annex Q, when performing media functions at transport level such as firewall or NAT, or appUcation 
level such as transcoding. The purpose of optimal media routing (OMR) is to identify and remove unnecessary media 
functions from the media path for each media stream associated to a session. The OMR procedures are applicable to the 
following IMS entities having IMS-ALG function used in a B2BUA mode: 

- P-CSCF for support of NAT for signaUing and media (with IMS-ALG/IMS-AGW model as described in TS 

23.228 [201]) Annex G) 

- IBCF for border Control Functions towards other IMS/SIP Networks (with IBCF/TrGW model as described in 

TS 23.228 [201] Aimexl) 

- Any AS performing as a B2BUA controlling media resources 

Although the different TS 23.228 [201] scenarios mainly address the IBCF/TrGW, they are also applicable to P-CSCF/ 
IMS-AGW, except for transcoding function which relates to IBCF only. Consequently, in the different flows, the "GW" 
stands for TrGW or IMS-AGW, according to the situation. 

The following flows focus on one IMS Node behaviour, embedding such IMS-ALG function supporting OMR, when 
involved in some of OMR scenarios described in TS 23.228 [201] Annex Q. 
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Each media line of the same session can be applied with separate OMR decision (i.e different optimised paths), 
however, for simplification, only one media is assumed in the following call flows. 

In the Figure, the "Originating side" may be an Originating UA or another IMS-ALG in the same IMS Network, or 
another IMS Network, and the "Destination side" may be a Terminating UA or another IMS-ALG in the same IMS 
Network, or another IMS Network. 

5.2.2.1 .19.1 IMS-ALG Related Procedures for OMR - Session establishment and IMS-ALG 

bypasses its local GW 

The following figure shows the session estabUshment with SDP offer/answer exchange from Originating side towards a 
Destination side, traversing an IMS Network Node including IMS-ALG function supporting OMR, and OMR results in 
IMS-ALG bypasses its local GW. 
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2. Interaction with GW 



3. Invite (SDP offer-out (R2, 



Realm R2 



OMR inf.), CaU-ID#out, ICID) 



More SIP Signalling 



4. 200 OK (SDP answer-out (Rl), CaU-ID#out) 



5.GW 
De-aUocation 



6. 200 OK (SDP answer-inc(Rl), Call-ID#inc) 



7. Accounting Request [Start] 



8. Open CDR with 

"Log GW Not Inserted" and 
"IP realm Not Default" 



9. Accounting Answer 



10. User Plane in Realm Rl 



Figure 5.2.2.1.19.1-1 : Message Sequence Chart for Session estabiishiment withi liUIS-ALG supporting 
OiUIR and liUIS-ALG bypasses its local GW due to OMR process. 

1. IMS-ALG receives an INVITE with SDP offer-inc (call-ID#-inc) from Originating side, containing the transport 
address allocated in realm Rl by the Originating side for the media on incoming leg, and potential OMR 
information from prior user plane segments. 

2. IMS-ALG determines the outgoing IP realm (R2) is different from the incoming IP realm (Rl) and interacts with 
a GW in order to allocate a local transport address for the media on outgoing leg, in realm R2. 
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3. IMS-ALG generates INVITE towards Destination side (call-ID#-out), with a new SDP offer-out including such 
local transport address, and also OMR extensions (for the segment locally handled, along with those received 
from prior user plane segments) for further OMR decisions. 

4. The destination side answers with 200 OK and SDP answer-out, with the transport address allocated by the 
destination side for the media on outgoing leg, as result of OMR processing (based on OMR information 
provided in step 3). This transport address is in realm Rl, thus identifying the local GW to be bypassed (i.e same 
IP realm as in step 1), and also identifying use of a different IP realm from the default one (i.e R2). 

5. The Local GW is de-allocated (release of resource allocated in step 2 in realm R2). 

6. IMS-ALG forwards the SDP answer-inc for the media on incoming leg, with this transport address received in 
step 4. 

7. IMS-ALG sends Accounting-Request with Accounting-Record-Type indicating START_RECORD to record start 
of session with "Local GW Not Inserted" and "IP realm Not Default"" indications for the media. 

8-9. The CDF opens a session CDR for the IMS Node and acknowledges the reception of the data. 

10. A user plane coimection is now established in realm Rl without GW insertion for the media. 
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5.2.2.1.19.2 



IMS-ALG Related Procedures for OMR - Session establishment and alternate IP 

realm is selected 



The following figure shows the session estabhshment with SDP offer/answer exchange from Originating side towards 
Destination side, traversing an IMS Network Node including IMS-ALG function supporting OMR, and OMR results in 
alternate IP realm selection (i.e not the default IP realm) for the media. 
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(OMR) 



Realm Rl 
< 



1. Invite (SDP offer-inc (Rl, OMR inf. prior segments), Call-ID#inc, ICID) 
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2. Interaction with 
GWl (R2) and GW2 (R3) 



Realm R2 



3. Invite (SDP offer-out (R2, al :ernate R3, OMR inf.), CaU-ID#out, ICID) 



More SIP Signalhng 




5. GWl de-allocation and 
Interaction with GW2 



6. 200 OK (SDP answer-inc(Rl), Cafl-IDttinc) 

7 Accounting Request [Start] 



10a. User Vlane in Realm Rl 



8. Open CDR with 
"Local GW Inserted" 
"IP re ahn Not Default" 



9. Accounting Answer 



10b. User Plane in Reahi R3 



Figure 5.2.2.1.19.2-1 : Message Sequence Chart for Session establishment with IIUIS-ALG supporting 
OIUIR, and alternate realm is selected due to OMR process. 

1. IMS-ALG receives an INVITE with SDP offer-inc (call-ID#-inc) from Originating side, containing the transport 
address allocated in realm Rl by the Originating side for the media on inconoing leg, and potential OMR 
information from prior user plane segments. 
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2. IMS-ALG determines the outgoing IP realm (R2) is different from the incoming IP realm (Rl) and interacts with 
a GWl in order to allocate a local transport address for the media on outgoing leg, in realm R2. IMS-ALG 
additionally interacts with GW2 in order to allocate an alternate local transport address for the media in realm 
R3. 

3. IMS-ALG generates INVITE towards Destination side (call-ID#-out), with a new SDP offer-out including such 
local transport addresses, and also OMR extensions (for the segment locally handled, along with those received 
from prior user plane segments) for further OMR decisions. 

4. The destination side answers with 200 OK and SDP answer-out, with the transport address allocated by the 
destination side for the media on outgoing leg, as result of OMR processing (based on OMR information 
provided in step 3).This transport address is in realm R3, thus identifying the local GW2 to be retained, and also 
identifying use of a different IP realm from the default one (i.e R2). 

5. The GWl is de-allocated (release of resource allocated in step 2 for realm R2), and interaction occurs with GW2 
to maintain the user plane connection via R3. 

6. IMS-ALGl forwards the SDP answer-inc, with the transport address allocated by the GW2 in realm Rl, for the 
media on incoming leg. 

7. IMS-ALG sends Accounting-Request with Accounting-Record-Type indicating START_RECORD to record start 
of session with "Local GW Inserted" and "IP realm Not Default" indications for the media. 

8-9. The CDF opens a session CDR for the IMS Node and acknowledges the reception of the data. 

lOa-b. A user plane connection is now established in realm Rl up to the GW2, and in realm R3 from the GW2 for 
the media. 
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5.2.2.1.19.3 



IMS-ALG Related Procedures for OMR - Mid-session procedure 



The following figure shows a scenario when a new SDP offer/answer exchange due to UE generating a SIP 
(Re-)INVITE or SIP UPDATE in mid-session in order to add a media component , and the OMR procedures is 
processed for this new media, with same situation as in 5.2.2.1.19.1 (IMS-ALG bypasses its local GW). 

This scenario also appUes for situations where a (Re-)INVITE or a SIP UPDATE is issued for updating a media and the 
OMR procedures is processed again, changing the estabUshed media path. 
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3. Re-Invite (SDP offer-o at (R2, OMR inf.), Call-ID#out, ICID) 



More SIP SignalUng 



4. 200 OK (SDP answe 



r-out (Rl). Call-ID#out) 



5.GW 
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6. 200 OK (SDP answer-inc(Rl), pall-ID#inc) 
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9. A 



ccountinsz Answc 



8. Update CDR with 

"Loc GW Not Inserted" and 
"IP reahn Not Default" 



1 0. User Plane in Realm Rl 



Figure 5.2.2.1.19.3-1 : Message Sequence Chart for mid-session procedure witli IIUIS-ALG supporting 
OIUIR, IIUIS-ALG bypasses its GW due to OMR process for the added media. 



The same steps described in chapter 5.2.2.1.19.1 apply, with following exceptions: 
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1 and 3: a Re-INVITE instead of INVITE 

7. IMS-ALG sends Accounting-Request with Accounting-Record-Type indicating INTERIM_RECORD to record 
update of session with "Local GW Not Inserted" and "IP realm Not Default" indications for the media. 

8-9. The CDF updates the session CDR for the IMS Node and acknowledges the reception of the data. 

5.2.2.1.19.4 IMS-ALG Related Procedures for OMR - transcoding 

As described in TS 23.228 [201 1 Annex Q, transcoding is also part of OMR process. 

The following flows show session establishment with SDP offer/answer exchange from Originating side towards a 
Destination side, traversing an IMS Network Node including IMS-ALG function supporting OMR with transcoder 
inserted by this IMS Node. 

Although transcoding aspect is part of the same SDP Offer/ Answer different exchanges described in sub-clause 
5.2.2.1.19.1 to sub-clause 5.2.2.1.19.3, therefore combined in OMR process, it is reflected here through dedicated flows 
for simpUfication. 

These procedures apply to IBCF/TrGW only. 

5.2.2.1 .19.4.1 IMS-ALG Related Procedures for OMR - transcoder provided by IMS-ALG 

The following flow describes the situation where IMS-ALG allocates a transcoder for offering an additional transcoding 
option, and this transcoder is selected. 
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Call-ID#inc) 



7. Accounting Request [Start] 



8. Open CDR with 
"Transcoder Inserted" 
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Figure 5.2.2.1.19.4.1-1 : Message Sequence Chart for Session establishment with transcoder offered 

by iiUIS-ALG is inserted. 

1. IMS-ALG receives an INVITE with SDP offer-inc (caU-ID#-inc) from Originating side, containing a codec-list- 
inc in the SDP offer, and potential OMR iirformation from prior user plane segments based on an Operator's 
configuration. 

2. IMS-ALG interacts with TrGW for transcoder allocation for the purpose of offering an additional codec "codec- 
out". 

3. IMS-ALG generates INVITE towards Destination side (call-ID#-out), the SDP offer-out containing the 
new codec-list-out (i.e codec-list-inc enriched with "codec-out"), and also OMR extensions (for 
transcoding options associated to different segments). 
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4. The destination side answers with 200 OK and SDP answer-out with the selected codec which is the additional 
one offered by IMS-ALG (i.e codec-out). 

5. Interaction occurs with TrGW for media configuration with codec-out for the outgoing leg and with codec-inc for 
the incoming leg (codec-inc is selected by IBCF from the codec-Ust-inc received in step 1). 

6. IMS-ALG forwards the SDP answer-inc for the incoming leg, with this codec-inc. 

7. IMS-ALG sends Accounting-Request with Accounting-Record-Type indicating START_RECORD to record start 
of session with "Transcoder Inserted" indication for the media. 

8-9. The CDF opens a session CDR for the IMS Node and acknowledges the reception of the data. 

5.2.2.1 .19.4.2 IMS-ALG Related Procedures for OMR - transcoder offered by IMS-ALG but not 

selected 

The following flow describes the situation where IMS-ALG allocates a transcoder for offering an additional transcoding 
option, and this transcoder is not selected. 
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Figure 5.2.2.1.19.4.2-1: iUlessage Sequence Cliart for Session establisliment witli transcoder offered 

by IMS-ALG is not selected. 

1. IMS-ALG receives an INVITE with SDP offer-inc (call-ID#-inc) from Originating side, containing a codec-list- 
inc in the SDP offer, and potential OMR information from prior user plane segments, based on an Operator's 
configuration. 

2. IMS-ALG interacts with TrGW for transcoder allocation for the purpose of offering additional codec "codec- 
out". 

3. IMS-ALG generates INVITE towards Destination side (call-ID#-out), the SDP offer-out containing the new 
codec-Ust-out (i.e codec-Ust-inc enriched with "codec-out"), and also OMR extensions (for transcoding options 
associated to different segments). 
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4. The destination side answers with 200 OK and SDP answer-out with the selected codec (codec-inc), belonging to 
the codec-list-inc received in step 1 (original offer). 

5. Therefore, transcoding is not needed, and TrGW is de-allocated. 

6. IMS-ALG forwards the SDP answer-inc for the incoming leg, with this codec-inc. 

7. IMS-ALG sends Accounting-Request with Accounting-Record-Type indicating START_RECORD to record start 
of session with "Transcoder Not Inserted" indication for the media. 

8-9. The CDF opens a session CDR for the IMS Node and acknowledges the reception of the data. 
5.2.2.1 .20 AS acting as a B2BUA - Single Cliarging session 

The following figure shows the case where an Application Server acts as a B2BUA, and a single offline charging 
session is created for the established dialogs ("OneChargingSession" option) 



ETSI 



3GPP TS 32.260 version 11.7.0 Release 11 



76 



ETSI TS 132 260 V1 1.7.0 (2013-04) 



Incoming side 



IMS Network 



AS 



1. Invite (TCID, Call-ID#iic) 



4. 200 OK (Call-ID#inc) 



CDF 



2. Invite (ICID, Call-ID#c 



3. 200OK(Call-lD#OLil) 



5. Accounting Request [Start, I ZID] 



ut) 



Open an AS CDR 



6. Accounting Answer 



Outgoing side 



Successful session establishment 



7.Re-Invite or Update (ICID, Call-ID#iic) 



10. 200 OK (CaIl-ID#inc) 



8.Re-Invite or Update (ICID, Call-ID#out) 



9. 200 OK (Call-ID#out) 



1 1 . Accounting Request [Interi m, ICID] 



update the AS CDR 



12. Accounting Answer 



Ongoing Session 



13. BYE (ICID, Call-ID#inc) 



18. 200 OK (Call-ID#inc) 



14. BYE (ICID, Call-ID fout) 



15. Accounting Request [Stop, ICID] 



Close the AS CDR 



16. Accounting Answer 



17. 200 OK (Call-ID#out) 



Figure 5.2.2.1.20-1 : Message Sequence Chart for AS acting as a B2BUA with single Charging session 

1. AS receives the INVITE from Inconning side (Call-ID#inc) containing ICID. 
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2. AS acting as a B2BUA generates INVITE towards Outgoing side (Call-ID#out) with the same ICID as received 
in step 1 . 

3. 200 OK is received in response to the INVITE (Call-ID#out). 

4. 200 OK is sent in response to the INVITE (CaU-ID#inc). 

5. AS sends Accounting-Request with Accounting-Record-Type indicating START_RECORD to record start of a 
session, provided with ICID and information associated to both Call-ID#inc and Call-ID#out. 

6. The CDF acknowledges the reception of the Accounting-Request with Accounting-Record-Type indicating 
START_RECORD and opens a AS CDR. 

7. AS receives a mid-session (e.g. in order to modify media component(s)) Re-INVITE or UPDATE from Incoming 

side (CalI-ID#inc) for the IMS session (ICID). 

8. AS generates Re-EWITE or UPDATE towards Outgoing side (CaU-ID#out) 

9-10. AS sends 200 OK (CaIl-ID#inc) towards Incoming side, when 200 OK (Call-ID#out) response is received 
from Outgoing side. 

11. AS sends an Accounting-Request with Accounting-Record-Type indicating INTERIM_RECORD to record 
changes associated to CalI-ID#inc or/and CaU-ID#out (e.g changed media component(s)) in the AS CDR for the 
IMS session (ICID). 

12. The CDF acknowledges the reception of the data and updates the AS CDR. 

13. AS receives BYE from Incoming side (CalI-ID#inc) 

14. AS sends BYE towards Outgoing side (CalI-ID#out) 

15. AS sends an Accounting-Request wilh Accounting-Record-Type indicating STOP_RECORD to record stop of a 
session in the AS CDR for the IMS session (ICID). 

16. The CDF acknowledges the reception of the data and closes the AS CDR. 

17-18. AS sends 200 OK(CalI-ID#inc) towards Incoming side, when 200 OK (CalI-ID#out) response is received 
from Outgoing side. 



5.2.2.1 .21 Session Establishment for Roaming Arcliitecture for Voice over IMS with Local 

Breakout 

The following figure shows the Diameter transactions initiated by the P-CSCF, S-CSCF, IBCF, and Transit and 
Roaming Function towards the CDF that are required for a Roaming Architecture for Voice over IMS with Local 
Breakout in each IMS network during session estabhshment. This example pertains to the flow in Aimex M.3.1.3 in TS 
23.228 [201] in which loopback and OMR procedures are apphed between the Visited Network and the Home Network 
serving UE A. 
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Figure 5.2.2.1.21-1 : lUlessage Sequence Cliart for Roaming Architecture for Voice over ilUIS witli Local 

Breakout with "VPLMN routing" and TRF 
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1 . The session initiation is acknowledged by the 200 OK by the termination side and received by the 
IBCF in the Visited Network A. 

la. IBCF sends Accounting-Request with Accounting-Record-Type indicating START_RECORD to 

record start of session with "Local GW Inserted" indication and with information on the non- 
roaming NNI 5 used for interconnection towards the terminating network. 

lb. The CDF acknowledges the reception of the data and opens an IBCF CDR. 

2. The Visited Network A TRF performs the loopback procedure and the session acknowledgement 
is routed towards the Home network through an IBCF . 

2a. Transit and Roaming Function sends Accounting-Request with Accounting-Record-Type indicating 

START_RECORD to record start of session and indicating loopback routing from the roaming 
NNI. 

2b. The CDF acknowledges the reception of the data and opens a TRF CDR. 

2c. IBCF sends Accounting-Request with Accounting-Record-Type indicating START_RECORD to 

record start of session with "Local GW Not Inserted" indication and with information on the 
roaming NNI 4 interconnecting to the intermediate network for the loopback path. 

2d. The CDF acknowledges the reception of the data and opens an IBCF CDR. 

2e. IBCF sends Accounting-Request with Accounting-Record-Type indicating START_RECORD to 

record start of session with "Local GW Not Inserted" indication and with information on the 
roaming NNI 3 interconnecting to the intermediate network for the loopback path. 

2f. The CDF acknowledges the reception of the data and opens an IBCF CDR. 

3. The S-CSCF in the Home Network A routes the session acknowledgement towards the Visited 
Network A through an IBCF. 

3a. S-CSCF sends Accounting-Request with Accounting-Record-Type indicating START_RECORD 

to record start of session and indicating loopback routing to the roaming NNI. 

3b. The CDF acknowledges the reception of the data and opens an IBCF CDR. 

3c. IBCF sends Accounting-Request with Accounting-Record-Type indicating START_RECORD to 

record start of session with "Local GW Not Inserted" indication and with information on the 
roaming NNI 2 interconnecting to the intermediate network for the non-loopback path. 

3d. The CDF acknowledges the reception of the data and opens an IBCF CDR. 

3e. IBCF sends Accounting-Request with Accounting-Record-Type indicating START_RECORD to 

record start of session with "Local GW Not Inserted" indication and with information on the 
roaming NNI 1 interconnecting to the intermediate network for the non-loopback path. 

3f. The CDF acknowledges the reception of the data and opens an IBCF CDR. 

3g. P-CSCF sends Accounting-Request with Accounting-Record-Type indicating START_RECORD 

to record start of session. 

3h. The CDF acknowledges the reception of the data and opens an IBCF CDR. 



5.2.2.1 .22 Service Continuity using ATCF 

Service Continuity using ATCF is specified in TS 23.237 [407]. 

Alternative "OneChargingSession"option is also reflected in the different flows description, i.e a single charging 
session from ATCF. 



5.2.2.1 .22.1 UE originating call (PS only or CS only) through ATCF 

In this flow, Call-ID #1 is for access leg and Call-ID #2 is for remote leg. 
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UE#1 Visited Networl< 
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— CS/IMS — 
Intermediate 
Nodes 



1. lnvite/_ 
' CS Setup 



12. 200 OK/ CS Connect 



ATCF/ 
ATGW 



-2. Invite- 
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media or not 



11. 200 OK 



CDF 



8. ACR(Start) 
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-7.200OK- 



9. Op e n ATCr CDR for th e 
rerrotelegCail-ID#2or 
9a. For the session when 
On e CDR 



13. ACR(Start)" 



Sl<ipped wheri 




14. Open ATCF CDR for 
the access ieg Cali-I[)#1 



-15. ACA- 



UE#1 Home Networl< 



IMS 

Intermediate 

Nodes, 
— sec AS 





Remote 




UE#2 




5. Invite 



M 6. 200 OK- 



Figure 5.2.2.1.22.1-1: Message Sequence Chart UE originating call through ATCF 

1. The sec session is initiated (an INVITE for IMS, a Call Setup for CS). 

2. After processing at CS/PS intermediate nodes, the resulting INVITE goes through the ATCF in the UE#1 serving 

network. 

3. The ATCF may decide whether to anchor the media session, and allocate if needed, ATGW resources to it. 

4. The ATCF forwards the INVITE request message to the UE#1 Home Network SCC AS 

5. The call setup proceeds and is routed to the remote UE-2 

6-7 On response 200 OK from the remote UE#2, response 200 OK is transmitted to UE#1 serving network 

8. Upon reception of the final response, the ATCF sends an Accounting-Request Wi\h Accounting-Record-Type 
indicating START_RECORD to record start of a user session/media component in the ATCF CDR for the IMS 
session. 

9-10. The CDF from the Serving network opens an ATCF CDR for the Remote leg (Call-ID#2) and acknowledges 
the reception of the data. 

9a-10 Alternatively, when "OneChargingSession", the CDF opens an ATCF CDR related to the IMS session, with 
Access leg and Remote leg, and acknowledges the reception of the data. 

11-12. The final response to SIP Invite (Call ID #1) is transmitted. 

13-15. Same as 8-9-10 but opening a ATCF CDR for the Access leg (Call-ID#1) 

.Steps 13 to 15 are not applicable for the "OneChargingSession" option. 
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5.2.2.1 .22.2 UE terminating call (PS only or CS only) through ATCF 

In this flow, Call-ID #1 is for access leg and Call-ID #2 is for remote leg. 



UE#1 Visited Netwoik 



SCUE#1 



— CS/IMS — 
Intermediate 
Nodes 



5.lnvite/_ 
' CS Setup 



6. 200 OK/ 



CS Connect 
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ATGW 



CDF 



3. Decision for anchoring 
media or not 



-4. Invite- 



7. 200 OK 



8. ACR(Statt) 



-2. Invite- 



9. Open ATCr CDR for the 
Access leg Cail-IID#1 or 
9a. For the session when 

OneCDR 



-10 ACA- 



13. ACR(Start) 



-1 1.200 OK- 



Sl^ipped when 
OneCDR 



14. Open ATCF CDR for 
the Remote leg Call-ilD#2 



-15. AC/V- 



UE#1 Home Network 

IMS 

Intermediate 

Nodes, 
— sec AS 





Remote 




UE#2 



-1. Invite- 



12 200 OK 



Figure 5.2.2.1.22.2-1: Message Sequence Chart UE terminating call through ATCF 

1. The sec session is initiated by UE #2 sending an INVITE towards UE-1 

2. The call setup proceeds and is routed to the UE-1 

3. The ATCF may decide whether to anchor the media session, and allocate if needed, ATGW resources to it. 

4. The ATCF forwards the INVITE request message to the CS/PS intermediate nodes. 

5. After processing at CS/PS intermediate nodes, the resulting message is sent to UE #1. 

6. The response is transmitted to CS/PS intermediate nodes. 

7. After processing at CS/PS intermediate nodes, the 200 OK message is sent to ATCF. 

8. Upon reception of the final response, the ATCF in the terminating network sends an Accounting-Request with 

Accounting-Record-Type indicating START_RECORD to record start of a user session/media component in the 
ATCF CDR. 

9-10. The CDF from the Terminating serving network opens an ATCF CDR for the Access leg (Call ID #1) and 
acknowledges the reception of the data. 
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9a-10 Alternatively, when "OneChargingSession", the CDF opens a ATCF CDR related to the IMS session (ICID) 
with Access leg and Remote leg, and acknowledges the reception of the data. 

1 1-12. The final response to SIP Invite (Call ID #2) is transmitted. 

13-15 Same as 8-9-10 but for the Remote leg (Call ID #2). 

.Steps 13 to 15 are not appUcable for the "OneChargingSession" option. 

5.2.2.1 .22.3 UE session transfer PS to CS using ATCF 

In this flow, Call-ID #1 is for PS access leg, Call-ID #1' for CS access leg and Call-ID #2 for remote leg. 
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MSG server P-CSCF 
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12. Update ATCF CDR for the 
rerrote leg Call-ID#2 or 
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UE#1 Home Network 



Intermediate 

Nodes, 
— sec AS 





Remote 




UE#2 



Figure 5.2.2.1.22.3-1 : Message Sequence Chart UE session transfer PS to CS using ATCF 

1. UE has an ongoing session under PS with media anchored in ATGW, and interactions between UE, RAN, 

MME/SGSN and MSC take place for session transfer to CS. 

2. MSC server sends the resulting INVITE towards the ATCF in the UE#1 serving network. 

3. The media session is anchored in ATGW: the ATCF updates the ATGW with new CS access leg ressource. 

4. The ATCF sends 200 OK answer to MSC server for switching the media path.. 

5-7. the ATCF sends an Accounting-Request with Accounting-Record-Type indicating START_RECORD to record 
start of a user session/media component in the ATCF CDR for the new CS access leg. 

5-6a-7. Alternatively, when "OneChargingSession", the CDF updates ATCF CDR related to the IMS session, with 
new Access leg, and acknowledges the reception of the data. 
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8. ACK from MSC server to ATCF 

9. The ATCF sends SIP LNVITE request via a new dialog to the SCC AS for indicating the transfer has taken place. 

10. The SCC AS sends a 200 OK confirmation response to the ATCF containing SDP answer stored during the 
original session estabhshment procedure. 

11-13. The ATCF in the terminating network sends an Accounting-Request with Accounting-Record-Type indicating 
INTERIM_RECORD to record update a user session in the ATCF CDR for the remote leg. 

12a-13 Alternatively, when "OneChargingSession", the CDF updates ATCF CDR related to the IMS session, and 
acknowledges the reception of the data. 

14. The ACTF acknowledges the 200 OK. 

15, 19-20 The SCC AS terminates the old PS access leg, by sending a SIP BYE request. 

16-18. The ATCF sends an Accounting-Request with Accounting-Record-Type indicating STOP_RECORD to close 
the ATCF CDR for the old PS access leg. 

Steps 16 to 18 are not applicable for the "OneChargingSession" option. 
5.2.2.1 .22.4 UE session transfer CS to PS using ATCF 

In this flow, Call-ID #1 is for PS access leg, Call-ID #1' for CS access leg and Call-ID #2 for remote leg. 
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Figure 5.2.2.1.22.4-1 : Message Sequence Chart UE session transfer CS to PS using ATCF 

1. UE has an ongoing session under CS with media anchored in ATGW, and interactions between UE, RAN, 

MME/SGSN and MSG take place for session transfer to PS. 

2. Transfer preparation procedure between MSG server and ATGF, the MSG interacts with UE for handover. 

3. The MSG server sends a SIP INFO request containing a session transfer preparation to the ATGF to instruct the 

ATGF that media should be switched to the new access leg. 

4. The ATGF sends 200 OK answer to MSG server for switching the media path.. 

5-7. the ATGF sends an Accounting-Request vnth Accounting-Record-Type indicating START_REGORD to record 
start of a user session/media component in the ATGF GDR for the new PS access leg. 

5-6a-7. Alternatively, when "OneChargingSession", the CDF updates ATGF GDR related to the IMS session, with 
new Access leg, and acknowledges the reception of the data. 

8-9. UE A sends an SIP INVITE request towards the ATGF to move the session control to the PS access. 
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10,14. The ATCF sends a 200 OK response to the UE. 

11-13. The ATCF sends an Accounting-Request wilh Accounting-Record-Type indicating INTERIM_RECORD to 
record update a user session in the ATCF CDR for the new access leg. 

12a-13. Alternatively, when "OneChargingSession", the CDF updates ATCF CDR related to the IMS session, and 
acknowledges the reception of the data. 

15-16. UE acknowledges the 200 OK. 

17. The ATCF sends SIP INVITE request via a new dialog to the SCC AS for indicating the transfer has taken 
place. 

18. The SCC AS sends a 200 OK confirmation response to the ATCF containing SDP answer stored during the 
original session estabhshment procedure. 

19-21. The ATCF sends an Accounting-Request vnth Accounting-Record-Type indicating INTERIM_RECORD to 
record update a user session in the ATCF CDR for the remote leg. 

20a-21. Alternatively, when "OneChargingSession", the CDF updates ATCF CDR related to the IMS session, and 
acknowledges the reception of the data. 

23, 27 The SCC AS terminates the old CS access leg, by sending a SIP BYE request. 

24-26. The ATCF sends an Accounting-Request v/ith Accounting-Record-Type indicating STOP_RECORD to close 
the ATCF CDR for the old CS access leg. 

Steps 24 to 26 are not apphcable for the "OneChargingSession" option. 



5.2.2.2 Message Flows - Error Cases and Scenarios 

This clause describes various error cases and how these should be handled. The error cases are grouped into the 
following categories: 

• Failure in SIP Related Procedures: 

Session Related Error Scenarios; 
- Session Unrelated Error Scenarios. 

• Errors in Diameter (Accounting) Related Procedures. 

5.2.2.2.1 Session Related SIP Procedures- Reception of SIP error messages 

A SIP session is closed abnormally by the reception of a BYE message indicating the reason for such termination. 
In this case, an ACR [Stop] message that includes an appropriate error indication is sent. 

5.2.2.2.2 Session Related SIP Procedures - SIP session failure 

All nodes involved in the SIP session are expected to exercise some kind of session supervision. In case a node detects 

an error in the SIP session, such as a timeout or the occurrence of an invalid SIP message that results in the inability to 
maintain the session, this IMS node will generate a BYE message towards both ends of the connection. 

The node that sent the BYE to trigger session termination identifies the cause of the failure in the ACR [Stop] towards 
the CDF. All other nodes, i.e. those that receive the BYE, are not aware of an error, and therefore they treat this 
situation as any normal SIP session termination. 
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5.2.2.2.3 Session Unrelated SIP procedures 

As described in clause 5.1.2.1.2, a session unrelated SIP procedure may either be completed with the reception of a 
200OK, or a SIP error message. If the latter occurs, i.e. there is a failure in the procedure, the ACR [Event] sent towards 
the CDF includes an appropriate error indication. 

5.2.2.2.4 CDF Connection Failure 

When the connection towards the primary CDF is broken, the process of sending accounting information should 
continue towards a secondary CDF (if such a CDF is configured). For further CDF connection failure functionality, see 
clause "Transport Failure Detection" in IETF RFC 3588 [401]. 

If no CDF is reachable the network element may buffer the generated accounting data in non-volatile memory. Once the 
CDF connection is working again, all accounting messages stored in the buffer is sent to the CDF, in the order they 
were stored in the buffer. 

5.2.2.2.5 No Reply from CDF 

In case an IMS node does not receive an ACA in reply to an ACR, it may repeat the ACR message. The waiting time 
until a repetition is sent, and the maximum number of repetitions are both configurable by the operator. When the 
maximum number of repetitions is reached and still no ACA reply has been received, the IMS node executes the CDF 
connection failure procedure as specified above. 

If retransmitted ACRs are sent, they are marked with the T-flag as described in IETF RFC 3588 [401] , in order to allow 
duplicate detection in the CDF, as specified in the next clause. 

5.2.2.2.6 Duplicate Detection 

A Diameter client marks possible duplicate request messages (e.g. retransmission due to the link failover process) with 
the T-flag as described in IETF RFC 3588 [401]. 

If the CDF receives a message that is marked as retransmitted and this message was already received, then it discards 
the duplicate message. However, if the original of the re-transmitted message was not yet received, it is the information 
in the marked message that is taken into account when generating the CDR. The CDRs are marked if information from 
duplicated message(s) is used. 

5.2.2.2.7 CDF Detected Failure 

The CDF closes a CDR when it detects that expected Diameter ACRs for a particular SIP session have not been 
received for a period of time. The exact behaviour of the CDF is operator configurable. 

5.2.3 CDR generation 

Editor's Note: FES 



5.2.4 GTP' record transfer flows 

GTP' is not used between CDF and CGF for IMS offline charging because CDF and CGF are combined into CCF (see 
clause 4.2). 

NOTE: Vendors may nevertheless implement a separate CDF and CGF for IMS offline charging. In this case, it is 
recommended that the approach chosen conforms to the principles and protocol applications specified in 
TS 32.295 [54]. 



5.2.5 Bi CDR file transfer 

The CGF will receive charging events from each AS involved in a SIP dialog. This may result in multiple CDRs, some 
of these CDRs may be redundant for billing purposes. When preparing these CDRs for the BD, the CGF may elect not 
to send some CDRs or may perform consolidation before transfer based on the operator's configuration. 



ETSI 



3GPP TS 32.260 version 11.7.0 Release 11 



87 



ETSI TS 132 260 V1 1.7.0 (2013-04) 



5.3 



IMS Online Charging Scenarios 



5.3.1 



Basic Principles 



IMS online charging uses the Credit Control appUcation that is specified in TS 32.299 [50]. 
Three cases for onUne charging are distinguished: 

• Immediate Event Charging (lEC); and 

• Event Charging with Unit Reservation (ECUR), and 

• Session Charging with Unit Reservation (SCUR) 

Both stage 2 and stage 3 mechanisms for the three cases for online charging are detailed in TS 32.299 [50]. 

In the case of Immediate Event Charging (lEC), granting units to the IMS network element is performed in a single 
operation that also includes the deduction of the corresponding monetary units from the subscriber's account. The 
charging process is controlled by the corresponding credit control request which is sent for a given credit control event. 

In contrast, Event Charging with Unit Reservation (ECUR) also includes the process of requesting, reserving, releasing 
and returning unused units for events. The deduction of the corresponding monetary units then occurs upon conclusion 
of the ECUR transaction. In this case, the credit control request is used to control the credit control session. 

Session Charging with Unit Reservation (SCUR) is used for credit control of sessions. SCUR also includes the process 
of requesting, reserving, releasing and returning unused units for sessions, and the deduction of the corresponding 
monetary units. During a SIP session there can be repeated execution of unit reservation and debit operations as 
specified in TS 32.299 [50]. 

The IMS network element may apply lEC, where CCR Event messages are generated, or ECUR, using CCR Initial, and 
Termination or SCUR. The decision whether to apply lEC, ECUR or SCUR is based on the service and/or operator's 
policy. 

The CTF uses CCR Initial, Update, Terminate in procedures related to successful SIP sessions. It uses CCR Events 
(Event or Initial, Terminate depending on whether lEC or ECUR/SCUR applies) for unsuccessfiil SIP sessions and for 
session unrelated procedures. Further details are specified in the tables below. 

It is operator configurable in the nodes for which SIP method a Credit Control Request is sent. The table below 
describes all possible CCRs that might be sent from an IMS OWE or an MRFC or an application server. 

It is configurable for the operators to enable or disable the generation of a CCR message by the IMS node in response to 
a particular "Triggering SIP Method". 
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Table 5.3.1.1 : Credit Control Request Messages Triggered by SIP lUlethods for IIUIS-GWF or AS 



r^isi motor 

Message 


Trinnorinn QID MothnH 

lliyycllliy oil IvIdllUvl 


CCR [Initial] 


Olr llN V 1 1 C ^OV_/Ur\J 


QIP MriTIPV /PPl \R\ 
olr InVJ llrY ^PL/Unj 


SIP MESSAGE (ECUR) 


QIP DPPICTPD (\^r^\ IDA 


SIP SUBSCRIBE (ECUR) 


SIP REFER (ECUR) 


SIP PUBLISH (ECUR) 


CCR [Update] 


SIP 200 OK acknowledging a SIP INVITE, RE-INVITE or SIP UPDATE [e.g. change in media 
components] (SCUR) 


RE-INVITE or SIP UPDATE [e.g. change in media components] (SCUR) 


Expiration of quota, Validity time expiry or other authorization triggers (quota threshold reached, ...). 

(SCUR) 


Any SIP message (except those triggering a CCR INITIAL or those not covered by the above triggers 
for CCR UPDATE) conveying a SDP offer or its associated SDP answer before SIP session 

establishment (SCUR) 


SIP 1xx provisional response, mid-dialog requests, mid-dialog responses and SIP INFO embedding 
RTTI XML body 


SIP Response (4xx, 5xx or 6xx), indicating an unsuccessful SIP RE-INVITE or SIP UPDATE (SCUR) 


CCR 

FTo rm i n ct to! 
[ 1 clIlllIlclLcJ 


SIP BYE message (both normal and abnormal session termination cases) (SCUR) 


olr iiuu ui\ acKnowieoying non-session reiaieu oir messages (tL/Un) 


ADoning a olr session sei-up procGaurG, using an internal iriggGr, or a oir uAiNUtL.^oouri/tuun) 


UGiGglSTraTIOn (SGG iNUItj (oUUri/tUUnj 


olr rinai riesponse ^xx (inciuoing response lo ritrtn, excepi oir ^uu \jr\j (tuunj 


olr rinai/rieQireCTIOn nesponse oXX ^oUUri/tUUri; 


olr rinai nesponse (4xx, oxx or oxxj, inaicaiing an unsuccessTui oir session set-up proceoure 
(cn\ |R\ 


.mp Final Rp^nnn^p (Ayy ^yy nr Ryy^ inHir?itinn an iin^iirrp^^fiil ^p^^inn-iinrplatprl nrnrpriiirp 

oil 1 1 1 1 Cll 1 iCOlJUl lOC y^AA, A A Ul UAA y , II lUI^QLI 1 1^ Cll 1 Li 1 lOLIOOCoOl Lil OCOO lUI 1 Lll II dClLCU \J\ UOCUU 1 C 

(ECUR) 


CCR [Event] 


SIP NOTIFY (lEC) 


SIP MESSAGE (lEC) 


SIP REGISTER (lEC) 


SIP SUBSCRIBE (lEC) 


SIP REFER (lEC) 


SIP PUBLISH (lEC) 


SIP Final Response (4xx, 5xx or 6xx), indicating an unsuccessful session-unrelated procedure (lEC) 



Table 5.3.1.2: Credit Control Request messages triggered by SIP IVIethods for MRFC 



CCR [Initial] 


SIP INVITE(SCUR) for initiating a multimedia ad hoc conferencing session 


CCR [Update] 


SIP RE-INVITE or SIP UPDATE[e.g. change in media components](SCUR) 


SIP BYE message 


Expiration of AVP[Acct-lnterim-lnterval](SCUR) 


CCR [Terminate] 


SIP BYE message(both normal and abnormal session termination cases)(SCUR) 


SIP Final Response with error codes 4xx, 5xx or 6xx indicating termination of an ongoing 

session(SCUR) 


SIP CANCEL(SCUR) 



NOTE: To the extent possible alignment with the IETF RFC 4006 [402] is planned. 
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5.3.2 Diameter Message Flows and Types 

This clause describes the message flows for the event charging procedures on the Ro interface. The IMS functions 
providing online charging via the Ro interface are the S-CSCF with IMS GWF, the AS and the MRFC. 

NOTE: The following subclauses only show the scenarios of the S-CSCF with IMS-GWF case and the AS case. The 
scenarios of the MRFC are FFS. 

5.3.2.1 Immediate Event Charging (lEC) 

This clause provides the details of the "Debit Units" operation specified in TS 32.299 [50]. 

5.3.2.1 .1 Message Flows - Successful Cases and Scenarios 

5.3.2.1 .1 .1 lEG - Debit Units Operation 

The transactions that are required on the Ro interface in order to perform lEC with Debit Units operations are carried 
out as described in TS 32.299 [50] where "CTF" refers to IMS network element. The Debit Units operation may 
alternatively be carried out prior to, concurrently with or after service/content delivery. The IMS network element must 
ensure that the requested service execution is successful, when this scenario is used. 

Editor's Note: Must be ahgned with TS 32.299 [50]. 
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5.3.2.1.1.2 



Scenarios 



The following figure shows the Diameter credit control transactions that are required between the IMS-GWF/AS and 
the OCS for session-unrelated IMS procedures, i.e. those that relate to the CCR [Event], as listed in Table 5.3.1. 

SIP messages and Diameter transactions associated with these charging scenarios are shown primarily for general 
information and to illustrate the charging triggers. They are not intended to be exhaustive and depend on the Diameter 
Credit Control Requests triggers configured by the operator. 

Scenario 1 : Successful session unrelated case 

NOTE: The Debit Units operation is carried out prior to service/content delivery. 



S-CSCF 



1. SIP Request (e.g. SUBSCRIBE) 



IMS-GWF 
/AS 



1. SIP Request (e.g. SUBSCRIBE) 



OCS 



Service control 



4. SIP Request (e.g. SUEISCRIBE) 



4. SIP Request 



2. Debit Unit Request [Event] 



Credit control 



3. Debit Unit Response [Event] 



(e.g. SUBSCRIBE) 



1 ) A session unrelated SIP Request (e.g. SUBSCRIBE) Is received In the S-CSCF. The S-CSCF fonwards this 
request to the IMS-GWF/AS. 

2) The IMS-GWF/AS sends a Debit Unit Request (CC-Request-Type=EVENT_REQUEST) to the OCS, 
requesting units in order to provide the service. 

3) The OCS sends the Debit Unit Response to acknowledge the Debit Unit Request, granting the requested 
units. 

4) The IMS-GWF/AS and the S-CSCF fonward the SIP Request. 

Figure 5.3.2.1.1.2-1 : lUlessage Sequence Chart for Session-Unrelated Procedure 



5.3.2.1 .2 Message Flows - Error Cases and Scenarios 

This clause describes various error cases and how these should be handled. 

The failure handling behaviour is locally configurable in the IMS network element. If the Direct-Debiting-Failure- 
Handling AVP is not used, the locally configured values are used instead. 

5.3.2.1 .2.1 Reception of SIP Error Messages 

If SIP errors in SIP response (4xx, 5xx or 6xx) occur during service delivery, as defined in TS 24.228 [202] and TS 
23.218 [203], it is up to the IMS network element to determine to what extent the service was delivered before the error 
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occurred and act appropriately with respect to charging. This may imply that no units at all (or no more units) are 
debited. 

5.3.2.1 .2.2 Debit Units Operation Failure 

This case comprises situations where either no, or an erroneous response, is received from the OCS. The "no response" 
case is detected by the IMS network element when the coimection supervision timer Tx expires (IETF RFC 4006 [402]) 
before a response Credit-Control-Answer (CCA) is received. The case of receiving an erroneous response implies that 
the IMS network element receives a Credit-Control-Answer (CCA), which it is unable to process, while Tx is running. 
The failure handling complies with the failure procedures for "Direct Debiting" scenario described in IETF RFC 4006 
[402]. 

5.3.2.1.2.3 Duplicate Detection 

The detection of duplicate request is needed and must be enabled. To speed up and simplify as much as possible the 
duplicate detection, the all-against-all record checking should be avoided and just those records marked as potential 
duphcates need to be checked against other received requests (within a reasonable time window) by the receiver entity. 

The IMS network element marks the request messages that are retransmitted after a link failover as possible duplicates 
with the T-flag as described in [201]. For optimized performance, uniqueness checking against other received requests 
is only necessary for those records marked with the T-flag received within a reasonable time window. This focused 
check is based on the inspection of the Session-Id and CC-Request-Number AVP pairs. 

5.3.2.2 Event Charging with Unit Reservation (ECUR) and Session Charging with 
Unit Reservation (SCUR) 

This clause provides the details of the "Reserve Units" and "Debit Units" operation specified in TS 32.299 [50]. 

5.3.2.2.1 Message Flows - Successful Cases and Scenarios 

5.3.2.2.1 .1 ECUR and SCUR - Reserve Units and Debit Units Operations 

The transactions that are required on the Ro interface in order to perform ECUR/SCUR with Reserve Units and Debit 
Units operations is carried out as described in TS 32.299 [50] where "CTF" refers to an IMS network element. Multiple 
repUcations of both of these operations are possible. 

5.3.2.2.1.2 Expiration of Reservation Validity 

This clause defines how reserved units are returned, if not used, within a reasonable time. It should be possible that 
both, reservation and SIP sessions are cancelled or only the reservation is cancelled without removing the SIP session. 

5.3.2.2.1.3 Scenarios 

The following figure shows the Diameter credit control transactions that are required between the IMS-GWF/AS and 
the OCS for session-related and session-unrelated IMS procedures. 

The SIP messages and Diameter transactions associated with these charging scenarios are shown primarily for general 
information and to illustrate the charging triggers. They are not intended to be exhaustive and they depend on the 
Diameter Credit Control Requests triggers configured by the operator. 
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5.3.2.2.1 .3.1 Session Related Procedures (SCUR). 

Scenario 1: Successful Session Establishment 

The following figure shows the Diameter credit control transactions that are required in the IMS-GWF/AS during a SIP 
session establishment. 



S-CSCF 



IMS-GWF 
/AS 



1. INVITE 



1. INVITE 



ocs 



Service control 



4. INVITE 



4. INVITE 



2. Reserve Unit Request [Initial] 



Credit control 



3. Reserve Unit Response [Initial] 



More SIP signalling and optionally more Reserve Unit Requests 



5. 200 OK (Invite) 




5. 200 OK (Invite) 



Service control 

6. Reserve Unit Request [Update] 



8. 200 OK (Invite) 



8. 200 OK (Invite) 



Credit control 



7. Reserve Unit Response [Update] 



1) An initial SIP Invite Request is received in the S-CSCF. This request is forwarded to the IMS-GWF/AS. 

2) The IMS-GWF/AS sends a Reserve Unit Request (CC-Request-Type =INITIAL_REQUEST) to the OCS 
requesting service units. The online credit control session Is Initiated. 

3) The OCS grants units In the Reserve Unit Response. 

4) The IMS-GWF/AS and S-CSCF forward the initial INVITE. 

5) A final response is received in the IMS-GWF/AS. 

6) If the trigger is active, the 200 OK answer triggers a Reserve Unit Request (CC-Request-Type 
=UPDATE_REQUEST) in the IMS-GWF/AS in order to update the credit control session. New service units 
are requested. Also the used service units (If any) are reported. 

7) The OCS sends the Reserve Unit Response to acknowledge the Reserve Unit Request. New service units 
are granted. 

8) The final answer Is fonwarded. 



Figure 5.3.2.2.1.3.1-1 : Message Sequence Chart for Successful Session Establishment 
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Scenario 2 : Successful Session Establisliment witli Early Media Negotiation 

The following figure shows the Diameter transactions that are required in the IMS-GWF/AS during a SIP session 
estabUshment in which SDP negotiation is completed before a final response to the initial INVITE is exchanged. 



S-CSCF 



1. SIP INVITE (SDP offer) 



Non final SIP Response 
(SDP Answer) 



IMS-GWF 
/AS 



1. SIP INVITE (SDP offer) 



OCS 



Service control 



4. SIP INVITE (SDP offer) 
•4 



4. SIP INVITE (SDP offer) 



5. Non final SIP Response (SDP Answer) 



2. Reserve Unit Request [Initial] 



Credit control 



3. Reserve Unit Responss [Initial] 



5. Non final SIF' Response (SDP Answer) 



Service control 

6. Reserve Unit Request [Update] 



Non final SIP Response 
(SDP Answer) 



Credit control 



7. Reserve Unit Response [Update] 



More SIP signalling and optionally more Reserve Unit Requests before INVITE final response 



2) 



3) 
4) 



1) An Initial SDP offer Is conveyed in a SIP INVITE nnessage. The SIP INVITE nnessage received in the S- 
CSCF is fonwarded to the IMS-GWF/AS. 

In this example, the SDP offer is conveyed in a SIP request which implies the start of the online session 
towards the OCS. The IMS-GWF/AS sends a Reserve Unit Request (CC-Request-Type 
=INITIAL_REQUEST) to the OCS requesting service units. The online credit control session is initiated. 
The OCS grants units in the Reserve Unit Response. 

The IMS-GWF/AS and S-CSCF forward the SIP Request conveying the SDP offer. 

5) A non-final SIP message (e.g. a provisional reliable response) conveying an SDP answer is received in the 
IMS-GWF/AS. 

6) The received SDP answer triggers a Reserve Unit Request (CC-Request-Type =UPDATE_REQUEST) in 
order to update the credit control session. New service units are requested. Also the used service units (if 
any) are reported. 

7) The OCS sends the Reserve Unit Response to acl<nowledge the Reserve Unit Request. New service units 
are granted. 

8) The SDP answer is forwarded. 



Figure 5.3.2.2.1.3.1-2 : lUlessage Sequence Chart for Session Establishment with Early Media 

Negotiation 



ETSI 



3GPP TS 32.260 version 11.7.0 Release 11 



94 



ETSI TS 132 260 V1 1.7.0 (2013-04) 



Scenario 3 : Mid-Session Procedures 

The figure shows the Diameter transactions that are required in the IMS-GWF/AS when receiving a SIP Re-INVITE in 
mid-session, e.g. in order to modify media component(s), or when the hold and resume procedure is executed. 



S-CSCF 



IMS-GWF 
/AS 



OCS 
(home) 



Ongoing SIP Session 



1. RE-INVITE 



1. RE-INVITE 



Service control 



4. RE-INVITE 



4. RE-INVITE 



2. Reserve Unit Request [Update] 



Credit control 



3. Reserve Unit Response 



[Update] 



More SIP signalling 



8. 200 OK (RE-INVITE) 



5. 200 OK (RE-INVITE) 



5. 200 OK (RE-INVITE) 



Service control 



8. 200 OK (RE-INVITE) 



6. Reserve Unit Request [Update] 



Credit control 
7. Reserve Unit Response [Update] 



1) 
2) 



3) 
4) 
5) 
6) 



7) 
8) 



A SIP RE-INVITE request Is received In the S-CSCF. This request Is forwarded to the IMS-GWF/AS. 

Upon receiving the SIP RE-INVITE request, the IMS-GWF/AS sends a Reserve Unit Request (CC-Request- 

Type = UPDATE_REQUEST) to update the previously initiated credit control session. New service units are 

requested. The used service units (if any) are also reported. 

The OCS grants new service units in the Reserve Unit Response. 

The RE-INVITE request is fonwarded. 

The RE-INVITE request is acknowledged with a 200 OK. 

If the trigger is active, the IMS-GWF/AS sends a Reserve Unit Request (CC-Request-Type 

=UPDATE_REQUEST) to the OCS to update the credit control session. New service units are requested. 

The used service units (if any) are also reported. 

The OCS grants new service units in the Reserve Unit Response. 

The 200 OK message is forwarded. 



Figure 5.3.2.2.1.3.1-3 : Message Sequence Chart for Mid-Session Procedures 
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Scenario 4: Session Release 

The following figure shows the Diameter transactions that are required in the IMS-GWF/AS for a session release 
scenario. 



1. BYE 



S-CSCF 



IMS-GWF 
/AS 



Ongoing SIP Session 



1. BYE 



Service controi 



2. BYE 



5. 200 OK 



5. 200 OK 



5. 200 OK 



2. BYE 



OCS 



3. Reserve Unit Request [Termination] 



Credit controi 
4. Reserve Unit Response [Termination] 



5. 200 OK 



1) A SIP session is released by sending a SIP BYE message. The S-CSCF forwards this message to the IMS- 
GWF/AS. 

2) Upon receiving the BYE message, the IMS-GWF/AS forwards the SIP BYE request to the UE. 

3) In case there is an ongoing online control session, the IMS-GWF/AS sends a Reserve Unit Request (CC- 
Request-Type =TERMINATION_REQUEST) reporting the used granted units. 

4) The OCS sends a Reserve Unit Response. The online credit control session is terminated. 

5) The final answer to the Bye message is forwarded. 



Figure 5.3.2.2.1.3.1-4 : iUlessage Sequence Chart for Session Release. 
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Scenario 5: Successful Session Establishment with reception of RTTI message 

The following figure shows the Diameter credit control transactions that are required in the IMS-GWF/AS during a SIP 
session establishment when RTTI message is received embedded in the SIP 200 OK. 



S-CSCF 



1. INVITE 



IMS-GWF 
/AS 



OCS 



1. INVITE 



Service control 



2. Reserve Unit Request [Initial] 



Credit control 



3. Reserve Unit Response [Initial] 



4. INVITE 



4. INVITE 



More SIP signalling and optionally more Reserve Unit Requests 



8. 200 OK (Invite) 



5. 200 OK 
RTTI XML body 



5. 200 OK 
RTTI XML body 



Service control 



6. Reserve Unit Request [Update, Tariff Information] 



Credit control 



7. Reserve Unit Response [Update] 



8. 200 OK (Invite) 



1) 
2) 

3) 
4) 
5) 
6) 



7) 
8) 



An initial SIP Invite Request is received in the S-CSCF. This request is forwarded to the IMS-GWF/AS. 
The IMS-GWF/AS sends a Reserve Unit Request (CC- Request-Type =INITIAL_REQUEST) to the OCS 
requesting service units. The online credit control session is initiated. 
The OCS grants units in the Reserve Unit Response. 
The IMS-GWF/AS and S-CSCF forward the initial INVITE. 

A final response is received in the IMS-GWF/AS, which embeds a RTTI XML body. 
If the trigger is active, the 200 OK answer triggers a Reserve Unit Request (CC- Request-Type 
=UPDATE_REQUEST) in the IMS-GWF/AS in order to update the credit control session and take into 
account the RTTI XML body within the SIP 200 OK (see NOTE). New service units are requested. Also the 
used service units (if any) are reported. 

The OCS sends the Reserve Unit Response to acknowledge the Reserve Unit Request. New service units 
are granted. 

The final answer is forwarded. 



NOTE: The mapping of RTTI XML body on Tariff Information structure is described in TS 32.280 [36]. 



Figure 5.3.2.2.1.3.1-5: Message Sequence Chart for Successful Session Establishment with reception 

of RTTI message 
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5.3.2.2.1 .3.2 Session Unrelated Procedures (ECUR). 

Scenario 1: Successful session unrelated procedure 

The following figure shows the Diameter transactions that are required in the IMS-GWF/AS for a session unrelated 
procedure. 
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S-CSCF 



IMS-GWF 
/AS 



OCS 



1 . SIP Request (e.g. SUBSCRIBE) 



1 . SIP Request (e.g. SUBSCRIBE) 



Service control 



4. SIP Request (e.g. SUElSCRIBE) 



4. SIP Request (e.g. SUElSCRIBE) 



2. Reserve Unit Request [Initial] 



Credit control 



3. Reserve Unit Response 



[Initial] 



More SIP signalling 



8. SIP Response 



5. SIP Response 



5. SIP Response 



Service control 



8. SIP Response 



6. Reserve Unit Request |Termination] 



Credit control 



7. Reserve Unit Response [Termination] 



1) A session unrelated SIP Request (e.g. SUBSCRIBE) is received in the S-CSCF. The S-CSCF forwards this 
request to the IMS-GWF/AS. 

2) The IMS-GWF/AS sends a Reserve Unit Request (CC- Request-Type = INITIAL_REQUEST) to initiate a 
credit control session. Service units are requested to the OCS. 

3) The OCS grants service units in the Reserve Unit Response. 

4) The IIViS-GWF/AS and the S-CSCF forward the SIP Request 

5) Depending on the used SIP method, there might be additional signalling between steps 4 and 5. 

6) The SIP Request is acknowledged by a SIP Response. 

7) The IMS-GWF/AS sends a Reserve Unit Request (CC-Request-Type=TERMINATION_REQUEST) to the 
OCS. It also reports the used granted units. 

8) The OCS sends a Reserve Unit Response to acknowledge the Reserve Unit Request. The online credit 

control session is terminated. 

9) The IMS-GWF/AS and S-CSCF forward the SIP Response. 



Figure 5.3.2.2.1.3.2-1 : Message Sequence Chart for Session-Unrelated Procedures 
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5.3.2.2.2 Message Flows - Error Cases and Scenarios 

This clause describes various error cases and how these should be handled. 

The failure handling behaviour is locally configurable in the IMS network element. If Credit-Control-Failure-Handling 
AVP is not used, the locally configured values are used instead. 

5.3.2.2.2.1 Reception of SIP Error Messages 

If SIP errors occur during service delivery, as defined in [202] and [203], it is up to the IMS network element to 
determine to what extent the service was delivered before the error occurred and act appropriately with respect to 
charging. This may imply that no units at all (or no more units) are reserved or debited. 

5.3.2.2.2.2 Reserve Units and Debit Units Operation Failure 

This case comprises of OCS connection failure, and/or receiving error responses from the OCS. 

The IMS network element detects an OCS connection failure when the timer Tx expires (IETF RFC 4006 [402]) or a 
transport failure is detected as defined in IETF RFC 3588 [401]. The OCS also has the capability to detect failures when 
the timer Ts (IETF RFC 3588 [401]) expires. The OCS should indicate the cause of failure by setting the appropriate 
result code as defined in IETF RFC 3588 [401] and IETF RFC 4006 [402]. In any case, the failure handUng of IMS 
network element and OCS compUes with the failure procedures for session based credit control scenario described in 
IETF RFC 4006 [402]. 

5.3.2.2.2.3 Duplicate Detection 

For credit control duplicate detection is performed only for possible duplicate event requests related to lEC as 
mentioned in clause 5.3.2.1.2.3, as retransmission of ECUR/SCUR related credit control requests is not allowed. 

5.3.2.2.2.4 Aborted Session Setup 

If a trigger occurs during session establishment to release a session during the establishment procedure, the IMS 
Network Element shall initiate procedures to cancel the session establishment as defined in TS 24.229 [204]. 
On completion of the cancellation procedure, the IMS Network Element shall close the credit-control session (for 
SCUR and ECUR) indicating an appropriate cause code. 

5.3.2.3 IMS Service Termination by OCS 

Annex B describes several scenarios related to IMS service termination. 

NOTE: The annex B only shows the scenario of the S-CSCF with IMS-GWF case. 

For IMS session related scenarios charged by means of SCUR in the IMS-GWF, Service Termination shall imply the 
rejection of a request for IMS session establishment or the release of an established session that is possibly associated to 
an online Diameter Charging Session. 

For IMS session unrelated scenarios charged by means of ECUR in the IMS-GWF, Service Termination shall imply the 
rejection of the SIP method triggering the Reserve Unit Request as defined in TS 32.299 [50]. 

For IMS session unrelated scenarios charged by means of lEC prior to service/content delivery in the IMS-GWF, 
Service Termination shall imply the rejection of the SIP method triggering the Debit Unit Request as defined in 
TS 32.299 [50]. 

5.3.2.3.1 Triggers on Ro interface which imply the termination of the IMS service 

The procedures in Ro interface which may trigger the IMS Service termination are the following: 

Reception of an unsuccessful Operation Result different from 

DIAMETER_CREDIT_CONTROL_NOT_APPLICABLE (TS32.299 [50]) in the Debit and Reserve Unit 
Response message. 
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Reception of an unsuccessful Result Code different from 

DIAMETER_CREDIT_CONTROL_NOT_APPLICABLE (TS32.299 [50]) within the Multiple Unit 
Operation in the Debit and Reserve Unit Response message when only one instance of the Multiple Unit 
Operation field is used. 

Execution of the Termination Action procedure as defined in TS32.299 [50] when only one instance of the 
Multiple Unit Operation field is used. 

Execution of the Failure Handling Procedures when the Failure Action is set to 'Terminate' or 'Retry & 
Terminate' . 

Reception in the IMS-GWF of an Abort-Session-Request Message from OCS. 

In case either a Final-Unit-Indication or an erroneous Result-Code at Multiple Unit Operation level trigger the IMS 
service termination and the charging is based on ECUR or SCUR, the IMS-GWF shall close the Diameter onUne 
session by sending a Debit Units and Reserve Units operation of Type 'Temoination'. 

Refer to TS 32.299 [50] for a detailed description of these procedures. 

5.3.2.3.2 Indication to the UE of the reason for IIVIS service release 

As a result of Service Termination triggering in IMS-GWF, the IMS service shall be denied to end-users. The network 
should provide an indication to UEs of the reason the service has been released or rejected. The procedure shall depend 
on: 

The charged party. 

The network should provide UEs with an indication of the reason the service has been released or rejected. 

However, this reason shall depend on whether the UE is the charged party or not. The premise is that only the 
charged party should know that the IMS service is being rejected / released because of OCS interaction. 

IMS specific protocol issues as defined in TS 24.229 [204]. 

A) The IMS-GWF generates a non-2xx final SIP response as a result of the IMS Service Termination 
procedure: 

In this scenario, the Response Code of the SIP response shall indicate the server understood the request but 
is refusing to fulfil it and that this request should not be repeated. The SIP response may include additional 
information about the cause to reject/release the IMS service. The presence of this additional error 
information in the response shall be operator configurable. 

The additional information included in the SIP response may contain a SIP URI. The UE may treat the SIP 
URI as if it were a Contact in a redirect and generate a new INVITE, resulting, for example, in a recorded 
annoimcement session being established. 

B) The IMS-GWF generates a SIP request (e.g. SIP BYE or SIP CANCEL) as a result of the IMS Service 
Termination procedure: 

In this scenario, the IMS-GWF may include a 'Reason' field in the request which provides additional 
information about the cause to reject/release the IMS service. The presence of this additional information in 
the request shall be operator configurable. 

In both scenarios, it shall also be operator configurable both per SIP Method and per Originating/Terminating 
side, the content of the additional error information sent to the UEs. This error information shall also be 
configurable based on the procedure in Ro interface which has triggered the release/rejection of the IMS service 
according to clause 5.3.2.3.1. In particular when the Service Termination is triggered by the reception of an 
unsuccessful Operation Result (different from DIAMETER_CREDIT_CONTROL_NOT_APPLICABLE as 
defined in TS 32.299 [50]) in the Debit and Reserve Unit Response message or the reception of an unsuccessful 
Result Code (different from DIAMETER_CREDIT_CONTROL_NOT_APPLICABLE as defined in 
TS 32.299 [50]) within the Multiple Unit Operation in the Debit and Reserve Unit Response message, the 
additional error information/reason shall also be configurable based on the Result Code received through Ro 
interface. 
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6 Definition of cliarging information 

6.1 Data description for IMS offline charging 
6.1 .1 Rf Message contents 

The IMS nodes generate accounting infonnation that can be transferred from the CTF to the CDF. For this purpose, 
IMS offline charging utilises the Charging Data Transfer that is specified in the 3GPP accounting apphcation described 
in TS 32.299 [50]. 

The Charging Data Transfer operation employs the Charging Data Request and Charging Data Response messages. 
The following table describes the use of these messages for offline charging. 



Table 6.1.1: Offline Charging IVIessages Reference Table 



Charging Data Request 


S-CSCF, l-CSCF, P-CSCF, MRFC, MGCF, BGCF, IBCF, 
AS, E-CSCF, IF, TRF, ATCF 


CDF 


Charging Data Response 


CDF 


S-CSCF, l-CSCF, P-CSCF, 
MRFC, MGCF, BGCF, IBCF, AS, 
E-CSCF, IF, TRF, ATCF 



6.1 .1 .1 Charging Data-Request Message 

The following table illustrates the basic structure of a Diameter Charging Data-Request message as used for IMS 
offline charging. 



Table 6.1.1.1: Charging Data Request Message Contents 



Field 


Category 




Session Identifier 


M 


Described in 32.299 [50] 


Originator Host 


M 


Described in 32.299 [50] 


Originator Domain 


M 


Described in 32.299 [50] 


Destination Domain 


M 


Described in 32.299 [50] 


Operation Type 


M 


Described in 32.299 [50] 


Operation Number 


M 


Described in 32.299 [50] 


Operation Identifier 


Om 


The field corresponds to tfie unique operation identification. 


User Name 


Oc 


Described in 32.299 [50] 


Operation Interval 


Oc 


TBD 


Origination State 


Oc 


TBD 


Origination Timestamp 


Oc 


This field contains the time when the operation is requested. 


Proxy Information 


Oc 


This field contains the parameter of the proxy. 


Route Information 


Oc 


This field contains the parameter of the route. 


Operation Token 


Om 


This field identifies the domain, subsystem, or service and release. 


Service Information 


Om 


This field holds the 3GPP specific IMS parameter, described in 6.3. 
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6.1 .1 .2 Charging Data Response Message 

The following table illustrates the basic structure of a Diameter Charging Data Response message as used for IMS 
offline charging. 



Table 6.1.1.2: Charging Data Response Message Contents 



IC 1 u ^^^^^^^^^ 


wciic^ui y 




Qpccinn IHontifior 


M 


XhiQ fiolH irlontifioQ tho nnoratinn QOCQinn 

1 1 llo 1 ICIU lUCI I LI 1 ICO LI IC \JlJd CI LIU 1 1 OCOOIUI I. 


Operation Result 


M 


This field identifies the result of the operation. 


Originator Host 


M 


This field contains the identification of the source point of the operation and the 
realm of the operation originator. 


Originator Domain 


M 


This field contains the realm of the operation originator. 


Operation Type 


M 


This field defines the transfer type: event for event based charging and start, 
interim, stop for session based charging. 


Operation Number 


M 


This field contains the sequence number of the transferred messages. 


Operation Identifier 


Om 


The field corresponds to the unique operation identification. 


User Name 


Oc 


The field contains the Private User Identity [201]. 


Operation Interval 


Oc 


TBD 


Origination State 


Oc 


TBD 


Origination Timestamp 


Oc 


This field contains the time when the operation is requested. 


Proxy Information 


Oc 


This field contains the parameter of the proxy. 



6.1 .2 GTP' message contents 



Not applicable. Refer to subclause 5.2.4 for further iirformation. 

6.1 .3 CDR Description on tine Bi Interface 
6.1.3.1 CDR Field Types 

The following Standard CDR content and format are considered: 

S-CSCF-CDR generated based on irrformation from the S-CSCF 

I-CSCF-CDR generated based on information from the I-CSCF 

P-CSCF-CDR generated based on information from the P-CSCF 

BGCF-CDR generated based on information from the BGCF 

IBCF-CDR generated based on information from the IBCF 

MGCF-CDR generated based on information from the MGCF 

MRFC-CDR generated based on information from the MRFC 

AS-CDR generated based on information from the AS 

E-CSCF-CDR generated based on information from the E-CSCF 

TF-CDR generated based on irrformation from the IMS Transit Fimctions 

TRF-CDR generated based on information from the TRF 

ATCF-CDR generated based on information from the ATCF 

The content of each CDR type is defined in the tables in clauses 6.1.3.3 to 6.1.3.11. For each CDR type the field 
definition includes the field name, category and description. The detailed field descriptions are provided in 
TS 32.298 [51]. 
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Editor's Note: Equipment vendors shall be able to provide all of the fields listed in the CDR content table in order to 
claim compliance with the present document. However, since CDR processing and transport consume 
network resources, operators may opt to eliminate some of the fields that are not essential for their 
operation. 

Editors note: Rephrase the above paragraph and ref. to 32.240 

The CDF provides the CDRs at the Bi interface in the format and encoding described in TS 32.298 [51]. Additional 
CDR formats and contents may be available at the interface to the billing system to meet the requirements of the billing 
system, these ai^e outside of the scope of 3GPP standardisation. 

6.1.3.2 CDR Triggers 

6.1.3.2.1 Session Related CDRs 

Reflecting the usage of multimedia sessions IMS CDRs are generated by the CDF on a per session level. In the scope of 
the present document the term "session" refers always to a SIP session. The coherent media components are reflected 
inside the session CDRs with a media component container comprising of all the information necessary for the 
description of a media component. 

Accounting information for SIP sessions is transferred from the CTF involved in the session to the CDF using Charging 
Data Request Start, Interim and Stop messages. A session CDR is opened in the CDF upon reception of a Charging 
Data Request [Start] message. Partial CDRs may be generated upon reception of a Charging Data Request [Interim] 
message, which is sent by the network entity towards the CDF due to a session modification procedure (i.e. change in 
media). Session CDRs are updated, or partial CDRs are generated upon reception of a Charging Data Request [Interim] 
message, which is sent by the network entity due to expiration of the Charging Data Interim Interval. The CDF closes 
the final session CDR upon reception of a Charging Data Request [Stop] message, which indicates that the SIP session 
is terminated. Further details on triggers for the generation of IMS CDRs are specified in [1]. 

Accounting information for unsuccessful session set-up attempts may be sent by the CTF to the CDF employing the 
Charging Data Request [Event] message. The behaviour of the CDF upon receiving Charging Data Request [Event] 
messages is specified in clause 6.1.3.2.2. 

6.1.3.2.2 Session Unrelated CDRs 

To reflect chargeable events not directly related to a session the CDF may generate CDRs upon the occurrence of 
session unrelated SIP procedures, such as registration respectively de-registration events. Accounting information for 
SIP session-unrelated procedures is transferred from the IMS nodes involved in the procedure to the CDF using 
Charging Data Request [Event] messages. Session unrelated CDRs are created in the CDF in a "one-off" action based 
on the information contained in the Charging Data Request [Event] message. One session unrelated CDR is created in 
the CDF for each Charging Data Request [Event] message received, whereas the creation of partial CDRs is not 
applicable for session unrelated CDRs. The cases for which the IMS nodes send Charging Data Request [Event] 
messages are listed per SIP procedure in table 5.2.1.1 and table 5.2.1.2. 

Further details on triggers for the generation of IMS CDRs are specified in clause 5.2.2. 
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6.1 .3.3 S-CSCF CDR Content 

The detailed description of the field is provided in TS 32.298 [51]. 



Table 6.1.3.3: Charging Data of S-CSCF CDR 



Record Type 


M 


Identifies the type of record. The parameter is derived from the Node functionality 

parameter. 


Retransmission 


Oc 


This parameter, when present, indicates that information from retransmitted Charging 
Data Requests has been used in this CDR 


SIP Method 


Oc 


Specifies the SIP-method for which the CDR is generated. Only available in session 
unrelated cases. 


Event 


Oc 


This field identifies the SIP event package to which the SIP request is referred. 


Expires Information 


Oc 


This field indicates the validity time of either the SIP message or its content, 
depending on the SIP method. 


Role of Node 


Om 


This field indicates whether the S-CSCF is serving the Originating or the Terminating 
party. 


Node Address 


Om 


This item holds the address of the node providing the information for the CDR. This 
may either be the IP address or the FQDN of the IMS node generating the accounting 
data. 


Session ID 


Om 


The Session identification. For a SIP session the Session-ID contains the SIP Call ID 
as defined in the Session Initiation Protocol RFC 3261 [404]. 


Session Priority 


Oc 


The field contains the priority of the session. 


List Of Calling Party 
Address 


Om 


The address or addresses (Public User ID or Public Service ID) of the party 
requesting a service or initiating a session. In the case of no P-Asserted-ldentify is 
known, this list shall include one item with the value "unknown". 


List of Associated 
URI 


Oc 


The list of non-barred public user identities (SIP URIs and/or TEL URIs) associated to 
the public user identity under registration. 


Called Party Address 


Om 


For SIP transactions, except for registration, this field holds the address of the party 

(Public User ID or Public Service ID) to whom the SIP transaction is posted. 
For registration transactions, this field holds the Public User ID under registration. 


Requested Party 
Address 


Oc 


For SIP transactions this field holds the address of the party (Public User ID or Public 

Service ID) to whom the SIP transaction was originally posted. 

This field is only present if different from the Called Party Address parameter. 


Number Portability 
routing information 


Oc 


This field includes information on number portability after DNS/ENUM request from S- 
CSCF in the calling user's home network. 


Carrier Select routing 
information 


Oc 


This field includes information on carrier select after DNS/ENUM request from S- 
CSCF in the calling user's home network. 


List of Called 
Asserted Identity 


Oc 


The address or addresses of the final asserted identities. Present if the final asserted 
identities are available in the SIP 2xx response. 


Private User ID 


Oc 


Holds the used private user identity of the served party according to RFC2486 [405] if 
available. 


List of Subscription 
Id 


Om 


Holds the public user identities of the served user 


Service Request 
Time Stamp 


Om 


This field contains the time stamp, which indicates the time at which the service was 
requested. 


Service Request 
Time Stamp Fraction 


Om 


This parameter contains the milliseconds fraction in relation to the Service Request 
Time Stamp. 


Service Delivery 
Start Time Stamp 


Om 


This field holds the time stamp reflecting either: successful session set-up, a delivery 

unrelated service, an unsuccessful session set-up and an unsuccessful session 
unrelated request. 


Service Delivery 
Start Time Stamp 
Fraction 


Om 


This parameter contains the milliseconds fraction in relation to the Service Delivery 
Start Time Stamp. 


Service Delivery End 
Time Stamp 


Oc 


This field records the time at which the service delivery was terminated. It is Present 
only in SIP session related case. 


Service Delivery End 
Time Stamp Fraction 


Oc 


This parameter contains the milliseconds fraction in relation to the Service Delivery 
End Time Stamp. 


Record Opening 
Time 


Oc 


A time stamp reflecting the time the CDF opened this record. Present only in SIP 
session related case. 


Record Closure Time 


Om 


A Time stamp reflecting the time the CDF closed the record. 


Application Servers 
Information 


Oc 


This a grouped CDR field containing the fields: "Application Server Involved" and 
"Application Provided Called Parties". 


Application 
Servers Involved 


Oc 


Holds the ASs (if any) identified by the SIP URIs. 
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Field 


Category 


Description 


Application 

i— \ 1 1 .11. . 1 

Provided Called 
Parties 


Oc 


Holds a list of the Called Party Address(es), if the address{es) are determined by an 
AS (SIP URI, E.164...). 


Status 


Oc 


Holds the abnormal status information of specific ASs (if any) when AS(s) respond 
4xx/5xx or time out to S-CSCF during an IMS session. 


List of Inter Operator 
Identifiers 


Oc 


1 1 1 1 Xl '1 XT' X' £ Ll I X 1 / ■ ■ X' 1 X ' X' \ 'X 1 1 

Holds the identification of the home network (originating and terminating) if exchanged 
via SIP signalling, as recorded in the P-Charging-Vector header. This grouped field 
may occur several times in one CDR. 


Originating lOi 


Oc 


This parameter corresponds to Orig-IOi header of the P-Charging-Vector defined in 
TS 24.229 [204]. 


Terminating 101 


Oc 


This parameter corresponds to Term-iOl header of the P-Charging-Vector defined in 
TS 24.229 [204]. 


Transit 101 List 


Oc 


This parameter corresponds to Transit-IOI List of the P-Charging-Vector defined in TS 
24.229 [204]. This field may occur several times in one CDR. 


Local Record 
Sequence Number 


Om 


This field includes a unique record number created by S-CSCF. The number is 
allocated sequentially for each partial CDR (or whole CDR) including all CDR types. 
The number is unique within the CDF. 


Record Sequence 
Number 


Oc 


This field contains a running sequence number employed to link the partial records 
generated by the CDF for a particular session. 


Cause For Record 
Closing 


Om 


This field contains a reason for the close of the CDR. 


Incomplete CDR 
Indication 


Oc 


This field provides additional diagnostics when the CDF detects missing Charging 
Data Requests. 


IMS Charging 
Identifier 


Om 


This parameter holds the IMS charging identifier (iCID) as generated by the IMS node 
for the SIP session. 


List of Early SDP 
Media Components 


Oc 


This is a grouped field which may occur several times in one CDR. 

Each occurrence shall describe a change in the state (inactive/active or vice versa) of 
the media components negotiated during the SIP session establishment previously to 
the reception of a SIP final response to the initial SIP Invite. 

^Fl '.£'11111x1 L '£ 1' X XX X' 1 X xl X' 1 

This field shall not be present if no media components are set to active before the final 
SIP session answer to the initial SIP Invite is received. 
This field can be present in either session or event CDRs. 


SDP Session 
Description 


Oc 


Holds the Session portion of SDP data exchanged in the above mentioned scenario, if 
available. 


SDP Type 


Om 


This parameter indicates if the SDP media component is an SDP offer or SDP 
answer. 


SDP Offer 
Timestamp 


Om 


This parameter contains the time of the SIP Request which conveys the SDP offer. 


SDP Answer 
Timestamp 


Om 


^ni L j_ ■ J.I X' J xl . . 1 /~\ 1 r-\ 1-^ . 1 ■ 1 

This parameter contains the time of the response to the SIP Request which conveys 
the SDP answer. 


SDP Media 

Components 


Om 


This is a grouped field comprising several sub-fields associated with one media 

component. Since several media components may exist for a session in parallel these 
sub-fields may occur several times. 


SDP Media 

Name 


Om 


This field holds the name of the media as available in the SDP data. 


SDP Media 
Description 


Om 


This field holds the attributes of the media as available in the SDP data. 


Access 
Correlation ID 


Oc 


This parameter holds the charging identifier from the access network, consisting of 
either GPRS charging ID (GCID) which is generated by the GGSN for a GPRS PDP 
context, Charging Id which is generated by P-GW for IP-CAN bearer or the Access 
Network Charging Identifier Value which is generated by another type of access 
network. 

It is present only if received from the access network when PCC architecture is 
implemented. 


Media initiator 

Flag 


Oc 


This field indicates if the called party has requested the session modification and it is 

present only if the initiator was the called party. 


List of SDP Media 
Components 


Oc 


This is a grouped field which may occur several times in one CDR. The first 
occurrence describes the initial SIP session negotiation whilst the other would stem 
from session re-negotiations. 

The field is present only in a SIP session related case. 


SDP Session 
Description 


Oc 


Holds the Session portion of the SDP data exchanged between the User Agents if 
available in the SIP transaction. 


SDP Type 


Om 


This parameter indicates if the SDP media component is an SDP offer or SDP 
answer. 
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rieiu 


Category 


Description ^^^^^H 


SIP Request 
Timestamp 


Oc 


This parameter contains the time of the SIP Request (usually a (Re)lnvite). 


SIP Response 
Timestamp 


Oc 


This parameter contains appropriately the time of 200 OK acl<nowledging an INVITE 
or of ACK including an SDP answer. 


SIP Request 
Timestamp Fraction 


Oc 


This parameter contains the milliseconds fraction in relation to the SIP Request 

Timestamp. 


SIP Response 
Timestamp Fraction 


Oc 


This parameter contains the milliseconds fraction in relation to the SIP Response 
Timestamp. 


SDP Media 
Components 


Om 


This IS a grouped field compnsing several sub-fields associated with one media 
component. Since several media components may exist for a session in parallel these 
sub-fields may occur several times. 


SDP Media 

Name 


Om 


This field holds the name of the media as available in the SDP data. 


SDP Media 
Description 


Om 


This field holds the attributes of the media as available in the SDP data. 


Access 
Correlation ID 


Oc 


This parameter holds the charging identifier from the access network, consisting of 
either GPRS charging ID (GCID) which is generated by the GGSN for a GPRS PDP 
context, Charging Id which is generated by P-GW for IP-CAN bearer or the Access 
Network Charging Identifier Value which is generated by another type of access 
network. 

It is present only if received from the access network when PCC architecture is 

implemented. 


IVIedia Initiator 
Flag 


Oc 


This field indicates if the called party has requested the session modification and it is 
present only if the initiator was the called party. 


GGSN Address 


Oc 


This parameter holds the control plane IP address of the GGSN that handles one or 
more media component(s) of an IMS session. 


Service Reason 
Return Code 


Om 


This parameter provides the returned SIP status code for the service request for the 
successful and failure case. 


List of Message 
Bodies 


Oc 


This grouped field comprising several sub-fields describing the data that may be 
conveyed end-to-end in the body of a SIP message. Since several message bodies 
may be exchanged via SIP-signalling, this grouped field may occur several times. 


Content-Type 


Om 


This sub-field of Message Bodies holds the MIME type of the message body, 
Examples are: application/zip, image/gif, audio/mpeg, etc. 


Content- 
Disposition 


Oc 


This sub-field of Message Bodies holds the content disposition of the message body 

■ 1 J. 1 1 1—4 1 1 ■ 1 Xl" 'X' 1 1 X'll I L it I JJ' 1" X 

inside the SIP signalling, Content-disposition header field equal to render , indicates 
that "the body part should be displayed or othenwise rendered to the user". Content 
disposition values are: session, render, inline, icon, alert, attachment, etc. 


Content-Length 


Om 


This sub-field of Message Bodies holds the size of the data of a message body in 

bytes. 


Originator 


Oc 


This sub-field of the "List of Message Bodies" indicates the originating party of the 
message body. 


Access Networl^ 
Information 


Oc 


This field contains the content of the SIP P-header "P-Access-Network-lnfo" if 
available. 


Service Context Id 


Om 


Holds the context information to which the CDR belongs. The information is obtained 
from the Operation Token of the Charging Data Request message. 


IMS Communication 
Service ID 


Oc 


This field contains the IMS communication service identifier if received in the P- 
Asserted-Service header in the SIP request. 


Online Charging Flag 


OC 


This field indicates the Online Charging Request was sent based on the provided ECF 
address from the SIP P-header "P-Charging-Function-Addresses". 
NOTE: No proof that online charging action has been taken 


Ro^l Ximo Tariff 
riccti 1 1 1 1 ic 1 di 1 1 1 

Information 




ThlQ fiolH hnlrlQ tho fariff/arlrl-nn pharno ropoix/orl 
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User Location Info 


oc 


This field indicates details of where the UE is currently located (e.g. SAI, TAI, RAI, 
CGI, ECGI or access-specific user location information) as specified in TS 23.228 
[2011. 


MS Time Zone 


oc 


This field indicates the offset between universal time and local time in steps of 15 
minutes of where the MS currently resides. 








NNI Infnrmatinn 

l^l^l IlllUlllfClllWll 


Oc 


Thi^ nrnnnpfi fipiri hnlHQ infnrmatinn ahoiit thp NNI iicipH fnr intprpntinprtinn anri 
roaming on the loopback routing path. It is present only if "VPLMN routing" is applied 
in a Roaming Architecture for Voice over IMS with Local breakout. 


NNI Type 


Oc 


This field indicates usage of the roaming NNI for loopback routing, i.e S-CSCF 
performed the loopback decision. 
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Field 


Category 


Description 


From Address 


Om 


Contains the information from the SIP From header. 


IMS Emergency 
Indication 


Oc 


This field indicates the registration is an emergency registration or the IIVIS session is 
an IMS emergency session, and is present only for emergency cases. 


IIVIS Visited Networl< 
Identifier 


Oc 


Contains the information from the SIP P-Visited-Network-ID header received in a 
REGISTER request. 


Record Extensions 


Oc 


A set of operator/manufacturer specific extensions to the record, conditioned upon 
existence of an extension. 



Editor's note: User Location Information and MS Time Zone to be updated after CTl stage 3 work is completed. 
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6.1 .3.4 P-CSCF CDR Content 

The detailed description of the field is provided in TS 32.298 [51]. 



Table 6.1.3.4: Charging Data of P-CSCF CDR 



I— Firl'' 


_Cateaorv 




Record Type 


M 


Identifies the type of record. The parameter is derived from the Node functionality 
parameter. 


Retransmission 


Oc 


This parameter, when present, indicates that information from retransmitted Charging 
Data Requests has been used in this CDR. 


SIP Metliod 


Oc 


Specifies the SIP-method for which the CDR is generated. Only available in session 
unrelated cases. 


Event 


Oc 


This field identifies the SIP event package to which the SIP request is referred. 


Expires 
Information 


Oc 


This field indicates the validity time of either the SIP message or its content, depending on 
the SIP method. 


Role of Node 


Om 


This field indicates whether the P-CSCF is serving the Originating or the Terminating 
party. 


Node Address 


Om 


This item holds the address of the node providing the information for the CDR. This may 
either be the IP address or the FQDN of the IMS node generating the accounting data. 


Session ID 


Om 


The Session identification. For a SIP session the Session-ID contains the SIP Call ID as 
defined in the Session Initiation Protocol RFC 3261 [404]. 


Session Priority 


Oc 


The field contains the priority of the session. 


List Of Calling 
Party Address 


Om 


The address (Public User ID or Public Service ID) of the party requesting a service or 
initiating a session. In the case of no P- Asserted- Identify is known, this list shall include 

one item with the value "unknown" 

Note: For P-CSCF, only one address is present 


List of Associated 
URI 


Oc 


The list of non-barred public user identities (SIP URIs and/or TEL URIs) associated to the 
public user identity under registration. 


Called Party 
Address 


Om 


In the context of an end-to-end SIP transaction this field holds the address of the party 
(Public User ID) to whom the SIP transaction is posted. For emergency calls, this 
parameter could contain an URN. 


List of Called 
Asserted Identity 


Oc 


The address or addresses of the final asserted identities. Present if the final asserted 
identities are available in the SIP 2xx response. 


Served Party IP 

Address 


Om 


This field contains the IP address of either the calling or called party, depending on 
whether the P-CSCF is in touch with the calling or called network. 


List of 

Subscription Id 


Om 


Holds the public user identities of the served user. 


Service Request 
Time Stamp 


Om 


This field contains the time stamp, which indicates the time at which the service was 
requested. 


Service Request 
Time Stamp 

Fraction 


Om 


This parameter contains the milliseconds fraction in relation to the Service Request Time 
Stamp. 


Service Delivery 
Start Time Stamp 


Om 


This field holds the time stamp reflecting either: successful session set-up, a delivery 
unrelated service, an unsuccessful session set-up and an unsuccessful session unrelated 
request. 


Service Delivery 
Start Time Stamp 
Fraction 


Om 


This parameter contains the milliseconds fraction in relation to the Service Delivery Start 
Time Stamp. 


Service Delivery 
End Time Stamp 


Oc 


This field records the time at which the service delivery was terminated. It is Present only 
in SIP session related case. Present with Charging Data Request [Stop]. 


Service Delivery 
End Time Stamp 
Fraction 


Oc 


This parameter contains the milliseconds fraction in relation to the Service Delivery End 
Time Stamp. 


Record Opening 
Time 


Oc 


A time stamp reflecting the time the CDF opened this record. Present only in SIP session 
related case. 


Record Closure 
Time 


Om 


A Time stamp reflecting the time the CDF closed the record. 


Inter Operator 
Identifiers 


Oc 


Holds the identification of the home network (originating and terminating) if exchanged via 
SIP signalling, as recorded in the P-Charging-Vector header. 


Originating 101 


Oc 


This parameter corresponds to Orig-IOI header of the P-Charging-Vector defined in TS 
24.229 [204]. 


Terminating 

101 


Oc 


This parameter corresponds to Term-IOI header of the P-Charging-Vector defined in TS 
24.229 [204]. 


Transit 101 List 


Oc 


This parameter corresponds to Transit-IOI List of the P-Charging-Vector defined in TS 
24.229 [204]. 
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Field 


Category 


Description 


Local Record 

Sequence 

Number 


Om 


This field includes a unique record number created by this node. The number is allocated 
sequentially for each partial CDR (or whole CDR) Including all CDR types. The number Is 
unique within the CDF. 


Record Sequence 
Number 


Oc 


This field contains a running sequence number employed to link the partial records 
generated by the CDF for a particular session. 


Cause For Record 
Closing 


Om 


This field contains a reason for the close of the CDR. 


Incomplete CDR 
Indication 


Oc 


This field provides additional diagnostics when the CDF detects missing Charging Data 
Requests. 


IMS Charging 
Identifier 


Om 


This parameter holds the IMS charging Identifier (iCID) as generated by the IMS node for 
the SIP session. 


Related IMS 
Charging Identifier 


Oc 


This parameter holds the Related IMS charging identifier when the session is the target 
access leg in an SRVCC CS to PS handover. The Related IMS charging identifier 
contains the IMS charging identifier as generated by the Enhanced MSC server. 


Related IMS 
Charging Identifier 
Generation Node 


Oc 


This parameter holds the identifier of the Enhanced MSC server that generated the 
Related IMS charging Identifier. 


List of Early SDP 
Media 

Components 


Oc 


This is a grouped field which may occur several times in one CDR. 
Each occurrence shall describe a change In the state (Inactive/active or vice versa) of the 
media components negotiated during the SIP session establishment previously to the 
reception of a SiP final response to the initial SIP invite. 

This field shall not be present if no media components are set to active before the final 
SIP session answer to the initial SIP Invite Is received. 
This field can be present in either session or event CDRs. 


oUr bession 
Description 


Oc 


Holds the Session portion of SDP data exchanged In the above mentioned scenario, if 
available. 


SDP Type 


Om 


This parameter Indicates If the SDP media component Is an SDP offer or SDP answer. 


SDP Offer 
Timestamp 


Om 


This parameter contains the time of the SIP Request which conveys the SDP offer. 


SDP Answer 
Timestamp 


Om 


^Pl • i x'j.lx' £xl xxl 1 X 1 ■ 1 xl 

This parameter contains the time of the response to the SIP Request which conveys the 
SDP answer. 


SDP Media 
Components 


Om 


^ni If" II iif"ii "xl "xl 1" 

This IS a grouped field compnsing several sub-fields associated with one media 
component. Since several media components may exist for a session In parallel these 

sub-fields may occur several times. 


SDP Media 

Name 


Om 


This field holds the name of the media as available in the SDP data. 


SDP Media 
Description 


Om 


This field holds the attributes of the media as available In the SDP data. 


Access 
Correlation ID 


Oc 


This parameter holds the charging identifier from the access network, consisting of either 
GPRS charging ID (GCID) which is generated by the GGSN for a GPRS PDP context, 
Charging Id which is generated by P-GW for IP-CAN bearer or the Access Network 
Charging Identifier Value which Is generated by another type of access network. 
It Is present only If received from the access network when PCC architecture Is 
implemented. 


Media Initiator 
Flag 


Oc 


This field indicates if the called party has requested the session modification and it is 
present only if the initiator was the called party. 


List of SDP Media 
Components 


Oc 


This is a grouped field which may occur several times In one CDR. The first occurrence 
describes the Initial session negotiation whilst the other would stem from session re- 
negotiations. 

The field is present only in a SIP session related case. 


SDP Session 
Description 


Oc 


Holds the Session portion of the SDP data exchanged between the User Agents if 
available In the SIP transaction. 


SDP Type 


Om 


This parameter Indicates If the SDP media component Is an SDP offer or SDP answer. 


SIP Request 
Timestamp 


Oc 


This parameter contains the time of the SIP Request (usually a (Re)lnvite). This 
parameter corresponds to SIP Request Timestamp in Charging Data Request [Interim]. 


SIP Response 

1 II 1 ICoLCll 1 l|J 


Oc 


This parameter contains appropriately the time of 200 OK acknowledging an INVITE or of 

AAV_/I\ IIIOIUUIII^ dll OL/n dl lo WCI . 1 1 no |JCll Ctl l ICLCI OUI l C70|JtJI lUo \\J <J\\ liCo|JUI IOC 1 II 1 ICoLCll 1 l|J 

in Charging Data Request. 


SIP Request 
Timestamp 
Fraction 


Oc 


This parameter contains the milliseconds fraction In relation to the SIP Request 
Timestamp. 


SIP Response 
Timestamp 
Fraction 


Oc 


This parameter contains the milliseconds fraction In relation to the SIP Response 
Timestamp. 
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Field 


Category 


Description 


SDP Media 
Components 


Om 


^ni I £' I I iix'ii 'xi'xi 1" 

This IS a grouped field compnsing several sub-fields associated with one media 
component. Since several media components may exist for a session in parallel these 
sub-fields may occur several times. 


SDP Media 

Name 


Om 


This field holds the name of the media as available in the SDP data. This parameter 
corresponds to SDP-Media-Name. 


SDP Media 
Description 


Om 


This field holds the attributes of the media as available in the SDP data. This parameter 
corresponds to SDP-Media-Descrlption. 


Local GW 
Inserted Indication 


Oc 


This field indicates whether the local IMS-AGW is inserted or not, for the media 
component included in SDP answer, if available. 


IP realm 
Default Indication 


Oc 


This field indicates whether the User Plane IP realm associated to the media component 
included in SDP answer, is the Default IP realm or not, if available. 


Access 
Correlation ID 


Oc 


This parameter holds the charging identifier from the access network, consisting of either 
GPRS charging ID (GCID) which is generated by the GGSN for a GPRS PDP context. 
Charging Id which is generated by P-GW for IP-CAN bearer or the Access Network 
Charging Identifier Value which is generated by another type of access network. 
It is present only if received from the access network when PCC architecture is 
implemented. 


Media Initiator 
Flag 


Oc 


This field indicates if the called party has requested the session modification and it is 
present only if the initiator was the called party. 


GGSN Address 


Oc 
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This parameter holds the control plane IP address of the GGSN that handles one or more 
media component(s) of a IMS session. 


Service Reason 
Return Code 


Om 


This parameter provides the returned SIP status code for the service request for the 
successful and failure case. 


List of Message 
Bodies 


Oc 


This grouped field comprising several sub-fields describing the data that may be 
conveyed end-to-end in the body of a SIP message. Since several message bodies may 
be exchanged via SIP-signalling, this grouped field may occur several times. 


Content-Type 


Om 


This sub-field of Message Bodies holds the MIME type of the message body. Examples 
are: application/zip, image/gif, audio/mpeg, etc. 


Content- 
Disposition 


Oc 


This sub-field of Message Bodies holds the content disposition of the message body 
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inside the SIP signalling. Content-disposition header field equal to render , indicates that 
"the body part should be displayed or otherwise rendered to the user". Content disposition 
values are: session, render, inline, icon, alert, attachment, etc. 


Content- 
Length 


Om 


This sub-field of Message Bodies holds the size of the data of a message body in bytes. 


Originator 


Oc 


This sub-field of the "List of Message Bodies" indicates the originating party of the 
message body. 


Access Network 
Information 


Oc 
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This field contains the content of the SIP P-header P-Access-Network-lnfo if available. 


Service Context Id 


Om 


Holds the context information to which the CDR belongs. The information is obtained from 
the Operation Token of the Charging Data Request message. 


IMS 

Communication 
bervice lU 


Oc 
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This field contains the IMS communication service identifier if received in the P-Asserted- 
Service header in the SIP request. 


IMS Application 
Reference ID 


Oc 


This field contains the IMS application reference identifier if received in the SIP request. 


User Location Info 


oo 


1 his field indicates details ot where the Ut is currently located (e.g. oAl, I Al, KAl, CGI, 
ECGI or access-specific user location information). 


MS Time Zone 


OC 


This field indicates the offset between universal time and local time in steps of 15 minutes 
of where the MS currently resides. 


From Address 


Um 


Contains the information from the SIP From header. 


IMS Emergency 
Indication 


Oc 


This field indicates the registration is an emergency registration or the IMS session is an 
IMS emergency session, and is present only for emergency cases. 


IMS Visited 
Network Identifier 


Oc 


Contains the information from the SIP P-Visited-Network-ID header sent in a REGISTER 
request. 


Record 
Extensions 


Oc 


A set of operator/manufacturer specific extensions to the record, conditioned upon 
existence of an extension. 



Editor's Note: The SIP parameter from which the IMS Application Reference ID (lARI) is to be extracted requires 
further investigation in CTl. A mechanism to identify the lARI in use is ffs. 

Editor's note: User Location Information and MS Time Zone to be updated after CTl stage 3 work is completed. 
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6.1 .3.5 l-CSCF CDR Content 

The detailed description of the field is provided in TS 32.298 [51]. 



Table 6.1.3.5: Charging Data of l-CSCF CDR 





Qateqorv 




Record Type 


M 


Identifies the type of record. The parameter is derived from the Node functionality 

parameter. 


Retransmission 


Oc 


This parameter, when present, indicates that information from retransmitted 
Charging Data Requests has been used in this CDR 


SIP Method 


Oc 


Specifies the SiP-method for which the CDR is generated. Only available in session 
unrelated cases. 


Event 


Oc 


This field identifies the SIP event package to which the SIP request is referred. 


Expires Information 


Oc 


This field indicates the validity time of either the SIP message or its content, 
depending on the SIP method. 


Role of Node 


Om 


This field indicates whether the l-CSCF is serving the Originating or the Terminating 
party. 


Node Address 


Om 


This item holds the address of the node providing the information for the CDR. This 
may either be the IP address or the FQDN of the IMS node generating the 

accounting data. 


Session ID 


Om 


The Session identification. For a SIP session the Session-ID contains the SIP Call ID 
as defined in the Session Initiation Protocol RFC 3261 [404]. 


Session Priority 


Oc 


The field contains the priority of the session. 


List Of Calling Party 
Address 


Om 


The address or addresses (Public User ID or Public Service ID) of the party 
requesting a service or initiating a session. In the case of no P-Asserted-ldentify is 
known, this list shall include one item with the value "unknown". 


List of Associated URI 


Oc 


The list of non-barred public user identities (SIP URIs and/or TEL URIs) associated 
to the public user identity under registration. 


Called Party Address 


Om 


In the context of an end-to-end SIP transaction this field holds the address of the 

party (Public User ID) to whom the SIP transaction is posted. 


Number Portability 
routing information 


Oc 


This field includes information on number portability after DNS/ENUM request from 
S-CSCF in the calling user's home network. 


Carrier Select routing 
information 


Oc 


This field includes information on carrier select after DNS/ENUM request from S- 
CSCF in the calling user's home network. 


Service Request Time 
Stamp 


Om 


This field contains the time stamp, which indicates the time at which the service was 
requested. This parameter corresponds to SIP Request Timestamp. Present with 
Charging Data Request [Event]. 


Service Request Time 
Stamp Fraction 


Om 


This parameter contains the milliseconds fraction in relation to the Service Request 
Time Stamp. 


Inter Operator 
Identifiers 


Oc 


Holds the identification of the home network (originating and terminating) if 
exchanged via SIP signalling, as recorded in the P-Charging-Vector header. 


Originating 101 


Oc 


This parameter corresponds to Orig-IOI header of the P-Charging-Vector defined in 
TS 24.229 [204]. 


Terminating 101 


Oc 


This parameter corresponds to Term-IOI header of the P-Charging-Vector defined in 
TS 24.229 [204]. 


Local Record 
Sequence Number 


Om 


This field includes a unique record number created by this node. The number is 
allocated sequentially for each partial CDR (or whole CDR) including all CDR types. 
The number is unique within the CDF. 


Cause For Record 
Closing 


Om 


This field contains a reason for the close of the CDR. 


Incomplete CDR 
Indication 


Oc 


This field provides additional diagnostics when the CDF detects missing Charging 
Data Requests. 


S-CSCF information 


Oc 


This field contains Information related to the serving CSCF, e.g. the S-CSCF 
capabilities upon registration event or the S-CSCF address upon the session 
establishment event. 


IMS Charging 

Identifier 


Om 


This parameter holds the IMS charging identifier (ICID) as generated by the IMS 

node for the SIP session. 


Service Reason 
Return Code 


Om 


This parameter provides the returned SIP status code for the service request for the 
successful and failure case. 


Access Networl< 
Information 


Oc 


This field contains the content of the SIP P-header "P-Access-Network-lnfo" if 
available. 


Service Context Id 


Om 


Holds the context information to which the CDR belongs. The information is obtained 
from the Operation Token of the Charging Data Request message. 


User Location Info 


OC 


This field indicates details of where the UE is currently located (e.g. SAI, TAI, RAI, 
CGI, ECGI or access-specific user location information). 



ETSI 



3GPP TS 32.260 version 11.7.0 Release 11 



112 



ETSI TS 132 260 V1 1.7.0 (2013-04) 



Field 


Category 


Description 


MS Time Zone 


OC 


This field indicates the offset between universal time and local time in steps of 15 
minutes of where the MS currently resides. 


From Address 


Om 


Contains the information from the SIP From header. 


IMS Emergency 
Indication 


Oc 


This field indicates the registration is an emergency registration, and is present only 
for emergency registrations. 


Record Extensions 


Oc 


A set of operator/manufacturer specific extensions to the record, conditioned upon 
existence of an extension. 



Editor's note: User Location Information and MS Time Zone to be updated after stage 3 work is completed. 
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6.1 .3.6 MRFC CDR Content 

The detailed description of the field is provided in TS 32.298 [51]. 



Table 6.1.3.6: Charging Data of MRFC CDR 





Cateaorv 




Record Type 


M 


Identifies the type of record. The parameter is derived from the Node functionality 
parameter. 


Retransmission 


Oc 


This parameter, when present, indicates that information from retransmitted 
Charging Data Requests has been used in this CDR. 


SIP Method 


Oc 


Specifies the SIP-method for which the CDR is generated. Only available in 
session unrelated cases. 


Event 


Oc 


This field identifies the SIP event package to which the SIP request is referred. 


Expires Information 


Oc 


This field indicates the validity time of either the SIP message or its content, 
depending on the SIP method. 


Node Address 


Om 


This item holds the address of the node providing the information for the CDR. 
This may either be the IP address or the FQDN of the IMS node generating the 
accounting data. 


Session ID 


Om 


The Session identification. For a SIP session the Session-ID contains the SIP Call 
ID as defined in the Session Initiation Protocol RFC 3261 [404]. 


Service ID 


Om 


This field identifies the service the MRFC is hosting. For conferences the 
conference ID is used here. 


Session Priority 


Oc 


The field contains the priority of the session. 


List Of Calling Party 
Address 


Om 


The address or addresses (Public User ID or Public Service ID) of the party 
requesting a service or initiating a session. In the case of no P-Asserted-ldentify is 
known, this list shall include a one item with the value "unknown". 


Called Party Address 


Oc 


For SIP transactions, except for registration, this field holds the address of the 
party (Public User ID or Public Service ID) to whom the SIP transaction is posted. 
For registration transactions, this field holds the Public User ID under registration. 


Requested Party 
Address 


Oc 


For SIP transactions this field holds the address of the party (Public User ID or 

Public Service ID) to whom the SIP transaction was originally posted. 

This field is only present if different from the Called Party Address parameter. 


List of Called Asserted 
Identity 


Oc 


The address or addresses of the final asserted identities. Present if the final 
asserted identities are available in the SIP 2xx response. 


List of Subscription Id 


Om 


Holds the public user identities of the served user 


Service Request Time 
Stamp 


Om 


This field contains the time stamp which indicates the time at which the service 
was requested. This parameter corresponds to SIP Request Timestamp. Present 
with Charging Data Request [Start] and Charging Data Request [Event]. 


Service Request Time 
Stamp Fraction 


Om 


This parameter contains the milliseconds fraction in relation to the Service 
Request Time Stamp. 


Service Delivery Start 
Time Stamp 


Om 


This field holds the time stamp reflecting either: successful session set-up, a 
delivery unrelated service, an unsuccessful session set-up and an unsuccessful 
session unrelated request. This parameter corresponds to SIP Response 
Timestamp. Present with Charging Data Request [Start] and Charging Data 
Request [EVENT]. 


Service Delivery Start 

Time Stamp Fraction 


Om 


This parameter contains the milliseconds fraction in relation to the Service 

Delivery Start Time Stamp. 


Service Delivery End 
Time Stamp 


Oc 


This field records the time at which the service delivery was terminated. It is 
Present only in SIP session related case. This parameter corresponds to SIP 
Request Timestamp. Present with Charging Data Request [Stop]. 


Service Delivery End 

Time Stamp Fraction 


Oc 


This parameter contains the milliseconds fraction in relation to the Service 

Delivery End Time Stamp. 


Record Opening Time 


Oc 


A time stamp reflecting the time the CDF opened this record. Present only in SIP 
session related case. 


Record Closure Time 


Om 


A Time stamp reflecting the time the CDF closed the record. 


Application Servers 
Information 


Oc 


This is a grouped CDR field containing the fields: "Application Server Involved" 

and "Application Provided Called Parties". 


Application Servers 
Involved 


Oc 


Holds the ASs (if any) identified by the SIP URIs. 


Application 
Provided Called Parties 


Oc 


Holds a list of the Called Party Address(es), if the address(es) are determined by 
an AS (SIPURI, E.164...). 


Inter Operator 
Identifiers 


Oc 


Holds the identification of the home network (originating and terminating) if 
exchanged via SIP signalling, as recorded in the P-Charging-Vector header. 


Originating 101 


Oc 


This parameter corresponds to Orig-IOI header of the P-Charging-Vector defined 
in TS 24.229 [204]. 
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Field 


Category 


Description 


Terminating 101 


Oc 


This parameter corresponds to Term-IOI header of the P-Charging-Vector defined 
in TS 24.229 [204]. 


Transit 101 List 


Oc 


This parameter corresponds to Transit-IOI List of the P-Charging-Vector defined in 
TS 24.229 [204]. 


Local Record 
Sequence Number 


Om 
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This field includes a unique record number created by this node. The number is 
allocated sequentially for each partial CDR (or whole CDR) including all CDR 
types. The number is unique within the CDF. 


Record Sequence 
Number 


Oc 


This field contains a running sequence number employed to link the partial records 
generated by the CDF for a particular session. 


Cause For Record 
Closing 


Om 


This field contains a reason for the close of the CDR. 


Incomplete CDR 
Indication 


Oc 


This field provides additional diagnostics when the CDF detects missing Charging 
Data Requests. 


IMS Charging Identifier 


Om 


This parameter holds the IMS charging identifier (iCID) as generated by the IMS 
node for the SIP session. 


List of Early SDP Media 
Components 


Oc 


This is a grouped field which may occur several times in one CDR. 
Each occurrence shall describe a change in the state (inactive/active or vice 
versa) of the media components negotiated during the SIP session establishment 
previously to the reception of a SIP final response to the initial SIP Invite. 

Tl_ ■ .£* 1 1 1— 11 J. 1 X '.I I' X XX X* 1— .C xi 

This field shall not be present if no media components are set to active before the 
final SIP session answer to the initial SIP Invite is received. 
This field can be present in either session or event CDRs. 


SDP Session 
Description 


Oc 


Holds the Session portion of SDP data exchanged in the above mentioned 
scenario, if available. 


SDP Type 


Om 


This parameter indicates if the SDP media component is an SDP offer or SDP 
answer. 


SDP Offer 
Timestamp 


Om 


This parameter contains the time of the SIP Request which conveys the SDP 
offer. 


SDP Answer 
Timestamp 


Om 


This parameter contains the time of the response to the SIP Request which 
conveys the SDP answer. 


SDP Media 
Components 


Om 


This is a grouped field comprising several sub-fields associated with one media 
component. Since several media components may exist for a session in parallel 
these sub-fields may occur several times. 


SDP Media 

Name 


Om 


This field holds the name of the media as available in the SDP data. 


SDP Media 
Description 


Om 


This field holds the attributes of the media as available in the SDP data. 


Access 
Correlation ID 


Oc 


This parameter holds the charging identifier from the access network, consisting of 
either GPRS charging ID (GCID) which is generated by the GGSN for a GPRS 
PDP context. Charging Id which is generated by P-GW for IP-CAN bearer or the 
Access Network Charging Identifier Value which is generated by another type of 
access network. 

It is present only if received from the access network when PCC architecture is 

implemented. 


Media Initiator Flag 


Oc 


This field indicates if the called party has requested the session modification and it 
is present only if the initiator was the called party. 


List of SDP Media 
Components 


Oc 


This is a grouped field which may occur several times in one CDR. The first 
occurrence describes the initial session negotiation whilst the other would stem 
from session re-negotiations. 
The field is present only in a SIP session related case 


SDP Session 
Description 


Oc 
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Holds the Session portion of the SDP data exchanged between the User Agents if 
available in the SIP transaction. 


SDP Type 


Om 


This parameter indicates if the SDP media component is an SDP offer or SDP 
answer. 


SIP Request 
Timestamp 


Oc 


This parameter contains the time of the SIP Request (usually a (Re)lnvite). This 
parameter corresponds to SIP Request Timestamp in the Charging Data Request 
[Interim]. 


SIP Response 

Timestamp 


Oc 


This parameter contains the time of the response to the SIP Request (usually a 
200 OK). This parameter corresponds to SIP Response Timestamp In the 
Charging Data Request [Interim]. 


SIP Request 
Timestamp Fraction 


Oc 


This parameter contains the milliseconds fraction in relation to the SIP Request 
Timestamp. 


SIP Response 
Timestamp Fraction 


Oc 


This parameter contains the milliseconds fraction in relation to the SIP Response 
Timestamp. 
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Field 


Category 


Description 


SDP Media 
Components 


Om 


This IS a grouped field compnsing several sub-fields associated with one media 
component. Since several media components may exist for a session in parallel 
these sub-fields may occur several times. 


SDP Media 

Name 


Om 


This field holds the name of the media as available in the SDP data. This 
parameter corresponds to SDP-Media-Name. 


SDP Media 
Description 


Om 


This field holds the attributes of the media as available in the SDP data. 


Access 
Correlation ID 


Oc 


This parameter holds the charging identifier from the access network, consisting of 
either GPRS charging ID (GCID) which is generated by the GGSN for a GPRS 
PDP context, Charging Id which is generated by P-GW for IP-CAN bearer or the 
Access Network Charging Identifier Value which is generated by another type of 
access network. 

It is present only if received from the access network when PCC architecture is 
implemented. 


Media Initiator Flag 


Oc 


This field indicates if the called party has requested the session modification and it 
is present only if the initiator was the called party. 


GGSN Address 


Oc 


This parameter holds the control plane IP address of the GGSN that handles one 
or more media component(s) of a IMS session. 


Service Reason Return 
Code 


Om 


This parameter provides the returned SIP status code for the service request for 
the successful and failure case. 


Access Network 
Information 


Oc 


This field contains the content of the SIP P-header "P-Access-Network-lnfo" if 
available. 


Service Context Id 


Om 


Holds the context information to which the CDR belongs. The information is 
ODiaineu irom ine ^jperaiion lOKen or ine onarging uaia nequesi message. 


rTT- ' H 

Unllne L/harglng rlag 




This field indicates the Online Charging Request was sent based on the provided 
ECF address from the SIP P-header "P-Charging-Function-Addresses". 
NOTE: No proof that online charging action has been taken 


User Location Info 


oc 


This field indicates details of where the UE is currently located (e.g. SAI, TAI, RAI, 
CGI, ECGI or access-specific user location information). 


MS Time Zone 


oc 


This field indicates the offset between universal time and local time in steps of 15 
minutes of where the MS currently resides. 


From Address 


Om 


Contains the information from the SIP From header. 


Record Extensions 


Oc 


A set of operator/manufacturer specific extensions to the record, conditioned upon 
existence of an extension. 



Editor's note: User Location Information and MS Time Zone to be updated after CTl stage 3 work is completed. 
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6.1 .3.7 MGCF CDR Content 

The detailed description of the field is provided in TS 32.298 [51]. 



Table 6.1.3.7: Charging Data of MGCF CDR 







■- ■ nA<snrintinn .-^^^^^^^^^^^^^^^H 


Record Type 


M 


Identifies the type of record. The parameter is derived from the Node 
functionality parameter. 


Retransmission 


Oc 


This parameter, when present, indicates that information from retransmitted 
Charging Data Requests has been used in this CDR 


SIP Method 


Oc 


Specifies the SIP-method for which the CDR is generated. Only available in 
session unrelated cases. 


Event 


Oc 


This field identifies the SIP event package to which the SIP request is referred. 


Expires Information 


Oc 


This field indicates the validity time of either the SIP message or its content, 
depending on the SIP method. 


Role of Node 


Om 


This field indicates whether the MGCF is serving the Originating or the 
Terminating party. 


Node Address 


Om 


This item holds the address of the node providing the information for the CDR. 
This may either be the IP address or the FQDN of the IMS node generating the 

accounting data. 


Session ID 


Om 


The Session identification. For a SIP session the Session-ID contains the SIP 
Call ID as defined in the Session Initiation Protocol RFC 3261 [404]. 


Session Priority 


Oc 


The field contains the priority of the session. 


List Of Calling Party 
Address 


Om 


The address or addresses (Public User ID or Public Service ID) of the party 
requesting a service or initiating a session. In the case of no P-Asserted-ldentify 
is known, this list shall include a one item with the value "unknown". 


Called Party Address 


Om 


In the context of an end-to-end SIP transaction this field holds the address of the 
party (Public User ID) to whom the SIP transaction is posted. 


Number Portability routing 

information 


Oc 


This field includes information on number portability after DNS/ENUM request 

from S-CSCF in the calling user's home network. 


Carrier Select routing 
information 


Oc 


This field includes information on carrier select after DNS/ENUM request from S- 
CSCF in the calling user's home network. 


Service Request Time 
Stamp 


Om 


This field contains the time stamp which indicates the time at which the service 
was requested. This parameter corresponds to SIP Request Timestamp. Present 

with Charging Data Request [Start] and Charging Data Request [Event]. 


Service Request Time 
Stamp Fraction 


Om 


This parameter contains the milliseconds fraction in relation to the Service 
Request Time Stamp. 


Service Delivery Start 
Time Stamp 


Om 


This field holds the time stamp reflecting either: successful session set-up, a 
delivery unrelated service, an unsuccessful session set-up and an unsuccessful 
session unrelated request. This parameter corresponds to SIP Response 
Timestamp. Present with Charging Data Request [Start] and Charging Data 
Request [Event]. 


Service Delivery Start 
Time Stamp Fraction 


Om 


This parameter contains the milliseconds fraction in relation to the Service 
Delivery Start Time Stamp. 


Service Delivery End 
Time Stamp 


Oc 


This field records the time at which the service delivery was terminated. It is 
Present only in SIP session related case. This parameter corresponds to SIP 

Request Timestamp. Present with Charging Data Request [Stop]. 


Service Delivery End 
Time Stamp Fraction 


Oc 


This parameter contains the milliseconds fraction in relation to the Service 
Delivery End Time Stamp. 


Record Opening Time 


Oc 


A time stamp reflecting the time the CDF opened this record. Present only in SIP 
session related case. 


Record Closure Time 


Om 


A Time stamp reflecting the time the CDF closed the record. 


Inter Operator Identifiers 


Oc 


Holds the identification of the home network (originating and terminating) if 
exchanged via SIP signalling, as recorded in the P-Charging-Vector header. 


Originating 101 


Oc 


This parameter corresponds to Orig-IOI header of the P-Charging-Vector defined 
in TS 24.229 [204]. 


Terminating 101 


Oc 


This parameter corresponds to Term-IOI header of the P-Charging-Vector 
defined in TS 24.229 [204]. 


Transit 101 List 


Oc 


This parameter corresponds to Transit-IOI List of the P-Charging-Vector defined 
in TS 24.229 [204]. 


Local Record Sequence 
Number 


Om 


This field includes a unique record number created by this node. The number is 
allocated sequentially for each partial CDR (or whole CDR) including all CDR 
types. The number is unique within the CDF. 


Record Sequence 
Number 


Oc 


This field contains a running sequence number employed to link the partial 
records generated by the CDF for a particular session. 
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rieiu 


Category 


Description 


Cause For Record 
Closing 


Om 


This field contains a reason for the close of the CDR. 


Incomplete CDR 
Indication 


Oc 


This field provides additional diagnostics when the CDF detects missing 
Charging Data Requests. 


IMS Charging Identifier 


Om 


This parameter holds the IMS charging identifier (ICID) as generated by the IMS 
node for the SIP session. 


List of Early SDP Media 
Components 


Oc 


This is a grouped field which may occur several times in one CDR. 

Each occurrence shall describe a change in the state (inactive/active or vice 

versa) of the media components negotiated during the SIP session 

establishment previously to the reception of a SIP final response to the initial SIP 

Invite. 

This field shall not be present if no media components are set to active before 
the final SIP session answer to the initial SIP Invite is received. 
This field can be present in either session or event CDRs. 






SDP Session 
Description 


Oc 


Holds the Session portion of SDP data exchanged in the above mentioned 
scenario, if available. 


SDP Type 


Om 


This parameter indicates if the SDP media component is an SDP offer or SDP 

answer. 


SDP Offer Timestamp 


Om 


This parameter contains the time of the SIP Request which conveys the SDP 
Otter. 


SDP Answer 

Timestamp 


Om 


This parameter contains the time of the response to the SIP Request which 

conveys the SDP answer. 


SDP Media 
Components 


Om 


This is a grouped field comprising several sub-fields associated with one media 
component. Since several media components may exist for a session in parallel 
these sub-fields may occur several times. 


SDP Media Name 


Om 


This field holds the name of the media as available in the SDP data. 


SDP Media 
Description 


Om 


This field holds the attributes of the media as available in the SDP data. 


Media Initiator Flag 


Oc 


This field indicates if the called party has requested the session modification and 
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It IS present only if the initiator was the called party. 


List of SDP Media 
Components 


Oc 


This is a grouped field which may occur several times in one CDR. The first 
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occurrence descnbes the initial session negotiation whilst the other would stem 
from session re-negotiations. 

The field is present only in a SIP session related case. 


SDP Session 
Description 


Oc 


II II xl X" £ xl |— \ 1 ■ 1 1 1 X xl 1 1 A X 

Holds the Session portion of the SDP data exchanged between the User Agents 
if available in the SIP transaction. 


SDP Type 


Om 


This parameter indicates if the SDP media component is an SDP offer or SDP 
answer. 


SIP Request 
Timestamp 


Oc 


This parameter contains the time of the SIP Request (usually a (Re)lnvite). This 
parameter corresponds to SIP Request Timestamp in Charging Data Request 
[Interim]. 


SIP Response 
Timestamp 


Oc 


This parameter contains appropriately the time of 200 OK acknowledging an 
INVITE or of ACK including an SDP answer. This parameter corresponds to SIP 
Response Timestamp in Charging Data Request [Interim]. 


SIP Request 
Timestamp Fraction 


Oc 


This parameter contains the milliseconds fraction in relation to the SIP Request 
Timestamp. 


SIP Response 
Timestamp Fraction 


Oc 


This parameter contains the milliseconds fraction in relation to the SIP Response 
Timestamp. 


SDP Media 
Components 


Om 


^FJ 1 1 1 1 1 X' 1 1 ■ X 1 'xl 1" 

This is a grouped field compnsing several sub-fields associated with one media 
component. Since several media components may exist for a session in parallel 
these sub-fields may occur several times. 


SDP Media Name 


Om 


This field holds the name of the media as available in the SDP data. This 

parameter corresponds to SDP-Media-Name. 


SDP Media 
Description 


Om 


This field holds the attributes of the media as available in the SDP data. 


Media Initiator Flag 


Oc 


This field indicates if the called party has requested the session modification and 
it is present only if the initiator was the called party. 


Service Reason Return 
Code 


Om 


This parameter provides the returned SIP status code for the service request for 

the successful and failure case. 


Trunk Group ID 

Incoming/Outgoing 


Um 


Contains the outgoing trunk group ID for an outgoing session/call or the incoming 

trunk group ID for an incoming session/call. 


Bearer Service 


Om 


Holds the used bearer service for the PSTN leg. 


Access Network 
Information 


Oc 


This field contains the content of the SIP P-header "P-Access-Network-lnfo" if 
available. 


Service Context Id 


Om 


Holds the context information to which the CDR belongs. The information is 
obtained from the Operation Token of the Charging Data Request message. 
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Real Time Tariff 
Information 


Oc 


This field holds the tariff/add-on charge received. 


From Address 


Om 


Contains the information from the SIP From header. 


Record Extensions 


Oc 


A set of operator/manufacturer specific extensions to the record, conditioned 
upon existence of an extension. 
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6.1 .3.8 BGCF CDR Content 

The detailed description of the field is provided in TS 32.298 [51]. 



Table 6.1.3.8: Charging Data of BGCF CDR 



Record Type 


Igtegory 

M 


Identifies the type of record. The parameter is derived from the Node functionality 
parameter. 


Retransmission 


Oc 


This parameter, when present, indicates that information from retransmitted 
Charging Data Requests has been used in this CDR. 


SIP Method 


Oc 


Specifies the SIP-method for which the CDR is generated. Only available in 
session unrelated cases. 


Event 


Oc 


This field identifies the SIP event package to which the SIP request is referred. 


Expires Information 


Oc 


This field indicates the validity time of either the SIP message or its content, 
depending on the SIP method. 


Role of Node 


Om 


This field indicates whether the BGCF is serving the Originating or the 
Terminating party. 


Node Address 


Om 


This item holds the address of the node providing the information for the CDR. 
This may either be the IP address or the FQDN of the IMS node generating the 

accounting data. 


Session ID 


Om 


The Session identification. For a SIP session the Session-ID contains the SIP 
Call ID as defined in the Session Initiation Protocol RFC 3261 [404]. 


Session Priority 


Oc 


The field contains the priority of the session. 


List Of Calling Party 
Address 


Om 


The address or addresses (Public User ID or Public Service ID) of the party 
requesting a service or initiating a session. In the case of no P-Asserted-ldentify 
is known, this list shall include a one item with the value "unknown". 


Called Party Address 


Om 


In the context of an end-to-end SIP transaction this field holds the address of the 
party (Public User ID) to whom the SIP transaction is posted. 


Number Portability routing 

information 


Oc 


This field includes information on number portability after DNS/ENUM request 
from S-CSCF in the calling user's home network. 


Carrier Select routing 
information 


Oc 


This field includes information on carrier select after DNS/ENUM request from S- 
CSCF in the calling user's home network. 


Service Request Time 
Stamp 


Om 


This field contains the time stamp which indicates the time at which the service 
was requested. This parameter corresponds to SIP Request Timestamp. Present 

with Charging Data Request [Start] and Charging Data Request [Event]. 


Service Request Time 
Stamp Fraction 


Om 


This parameter contains the milliseconds fraction in relation to the Service 
Request Time Stamp. 


Service Delivery Start 
Time Stamp 


Om 


This field holds the time stamp reflecting either: successful session set-up, a 
delivery unrelated service, an unsuccessful session set-up and an unsuccessful 
session unrelated request. This parameter corresponds to SIP Response 
Timestamp. Present with Charging Data Request [Start] and Charging Data 
Request [Event]. 


Service Delivery Start 
Time Stamp Fraction 


Om 


This parameter contains the milliseconds fraction in relation to the Service 
Delivery Start Time Stamp. 


Service Delivery End 
Time Stamp 


Oc 


This field records the time at which the service delivery was terminated. It is 
Present only in SIP session related case. This parameter corresponds to SIP 

Request Timestamp. Present with Charging Data Request [Stop]. 


Service Delivery End 
Time Stamp Fraction 


Oc 


This parameter contains the milliseconds fraction in relation to the Service 
Delivery End Time Stamp. 


Record Opening Time 


Oc 


A time stamp reflecting the time the CDF opened this record. Present only in SIP 
session related case. 


Record Closure Time 


Om 


A Time stamp reflecting the time the CDF closed the record 


Inter Operator Identifiers 


Oc 


Holds the identification of the home network (originating and terminating) if 
exchanged via SIP signalling, as recorded in the P-Charging-Vector header. 


Originating 101 


Oc 


This parameter corresponds to Orig-IOI header of the P-Charging-Vector defined 
in TS 24.229 [204]. 


Terminating 101 


Oc 


This parameter corresponds to Term-IOI header of the P-Charging-Vector 
defined in TS 24.229 [204]. 


Transit 101 List 


Oc 


This parameter corresponds to Transit-IOI List of the P-Charging-Vector defined 
in TS 24.229 [204]. 


Local Record Sequence 
Number 


Om 


This field includes a unique record number created by this node. The number is 
allocated sequentially for each partial CDR (or whole CDR) including all CDR 
types. The number is unique within the CDF. 


Record Sequence 
Number 


Oc 


This field contains a running sequence number employed to link the partial 
records generated by the CDF for a particular session. 
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rieiu 


Category 


Description ^^^^^^^^^^^^^^^^^H 


Cause For Record 
Closing 


Om 


This field contains a reason for the close of the CDR. 


Incomplete CDR 
Indication 


Oc 


This field provides additional diagnostics when the CDF detects missing Charging 
Data Requests. 


IMS Charging Identifier 


Om 


This parameter holds the IMS charging identifier (ICID) as generated by the IMS 
node for the SIP session. 


List of Early SDP Media 
Components 


Oc 


This is a grouped field which may occur several times in one CDR. 

Each occurrence shall describe a change in the state (inactive/active or vice 

versa) of the media components negotiated during the SIP session establishment 

previously to the reception of a SIP final response to the initial SIP Invite. 

This field shall not be present if no media components are set to active before the 

final SIP session answer to the initial SIP Invite is received. 

This field can be present in either session or event CDRs. 


SDP Session 
Description 


Oc 


Holds the Session portion of SDP data exchanged in the above mentioned 
scenario, if available. 


SDP Type 


Om 


This parameter indicates if the SDP media component is an SDP offer or SDP 

answer. 


SDP Offer Timestamp 


Om 


This parameter contains the time of the SIP Request which conveys the SDP 
otter. 


SDP Answer 
Timestamp 


Om 


This parameter contains the time of the response to the SIP Request which 
conveys the SDP answer. 


SDP Media 
Components 


Om 


This is a grouped field comprising several sub-fields associated with one media 
component. Since several media components may exist for a session in parallel 
these sub-fields may occur several times. 


SDP Media Name 


Om 


This field holds the name of the media as available in the SDP data. 


SDP Media 

Description 


Om 


This field holds the attributes of the media as available in the SDP data. 


Media Initiator Flag 


Oc 


This field indicates if the called party has requested the session modification and 

'X ■ X 1 'X xl ' 'X' X xl III ■ 

It IS present only if the initiator was the called party. 


List of SDP Media 
Components 


Oc 


This is a grouped field which may occur several times in one CDR. The first 
occurrence describes the initial session negotiation whilst the other would stem 
from session re-negotiations. 
The field is present only in a SIP session related case. 


SDP Session 
Description 


Oc 


Holds the Session portion of the SDP data exchanged between the User Agents 
if available in the SIP transaction. 


SDP Type 


Om 


This parameter indicates if the SDP media component is an SDP offer or SDP 
answer. 


SIP Request 
Timestamp 


Oc 


This parameter contains the time of the SIP Request (usually a (Re)lnvite). This 
parameter corresponds to SIP Request Timestamp in Charging Data Request 
[Interim]. 


SIP Response 

Timestamp 


Oc 


This parameter contains appropriately the time of 200 OK acknowledging an 
INVITE or of ACK including an SDP answer. This parameter corresponds to SIP 
Response Timestamp in Charging Data Request [Interim]. 


SIP Request 
Timestamp Fraction 


Oc 


This parameter contains the milliseconds fraction in relation to the SIP Request 
Timestamp. 


SIP Response 
Timestamp Fraction 


Oc 


This parameter contains the milliseconds fraction in relation to the SIP Response 
Timestamp. 


SDP Media 
Components 


Om 


This is a grouped field comprising several sub-fields associated with one media 
component. Since several media components may exist for a session in parallel 
these sub-fields may occur several times. 


bUr Media Name 


Om 


This field holds the name of the media as available in the SDP data. 


SDP Media 

Description 


Om 


This field holds the attributes of the media as available in the SDP data. 


Media Initiator Flag 


Oc 


This field indicates if the called party has requested the session modification and 
it is present only if the initiator was the called party. 


Service Reason Return 
Code 


Om 


This parameter provides the returned SIP status code for the service request for 
the successful and failure case, 


Access Network 
Information 


Uc 


This field contains the content of the SIP P-header "P-Access-Network-lnfo" if 

available. 


Service Context Id 


Om 


Holds the context information to which the CDR belongs. The information is 
obtained from the Operation Token of the Charging Data Request message. 


From Address 


Om 


Contains the information from the SIP From header. 


Record Extensions 


Oc 


A set of operator/manufacturer specific extensions to the record, conditioned 
upon existence of an extension. 
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NNI Information 


Oc 


This grouped field holds information about the NNI used for interconnection and 
roaming on the loopback routing path. It is present only if RAVEL "VPLMN 
routing" is applied. 


NNI Type 


Oc 


This field Indicates usage of the roaming NNI for loopback routing, i.e BGCF 
performed the loopback decision. 
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6.1 .3.9 SIP AS CDR Content 

The detailed description of the field is provided in TS 32.298 [51]. 



Table 6.1.3.9: Charging Data of AS CDR 





.Category 


DescrlDtion ^^.^^^^^^^^^^^H 


Record Type 


M 


Identifies the type of record. The parameter is derived from the Node 
functionality parameter. 


Retransmission 


Oc 


This parameter, when present, indicates that information from 
retransmitted Charging Data Requests has been used in this CDR 


SIP Method 


Oc 


Specifies the SIP-method for which the CDR is generated. Only 
available in session unrelated cases. 


Event 


Oc 


This field identifies the SIP event package to which the SIP request is 
referred. 


Expires Information 


Oc 


This field indicates the validity time of either the SIP message or its 
content, depending on the SIP method. 


Role of Node 


Om 


This field indicates whether the AS is serving the Originating or the 
Terminating party. 


Node Address 


Om 


This item holds the address of the node providing the information for 
the CDR. This may either be the IP address or the FQDN of the IMS 
node generating the accounting data. 


Session ID 


Om 


The Session identification. For a SIP session the Session-ID contains 
the SIP Call ID as defined in the Session Initiation Protocol RFC 
3261 [404]. When the AS acts as B2BLIA, the incoming session is 
identified , except for the "OneChargingSession" option, where it 
contains either the incoming or outgoing dialog SIP Call Id involved 
during IMS session setup. 


Outgoing Session ID 


Oc 


When the AS acts as B2BUA, the outgoing session is identified by 
the Outgoing Session ID which contains the SIP Call ID (as defined 

in the RFC 3261 [404]). This field is not used for the 
"OneChargingSession" option 


Session Priority 


Oc 


The field contains the priority of the session. 


List Of Calling Party Address 


Om 


The address or addresses (Public User ID or Public Service ID) of 
the party requesting a service or initiating a session. In the case of no 
P-Asserted-ldentify is known, this list shall include a one item with the 
value "unknown". 


Called Party Address 


Om 


For SIP transactions, except for registration, this field holds the 
address of the party (Public User ID or Public Service ID) to whom 
the SIP transaction is posted. 

For registration transactions, this field holds the Public User ID under 
registration. 


Number Portability routing information 


Oc 


This field includes information on number portability after DNS/ENUM 
request from S-CSCF in the calling user's home network. 


Carrier Select routing information 


Oc 


This field includes information on carrier select after DNS/ENUM 
request from S-CSCF in the calling user's home network. 


Alternate Charged Party Address 


Oc 


The address of an alternate party that is identified by the AS at 
session initiation, and is charged in place of the calling party. 


List of Requested Party Address 


Oc 


This field is a list of Requested Party Address. 
Each occurrence contains: 

For SIP transactions ,the address of the party (Public User ID or 
Public Service ID) to whom the SIP transaction was originally posted. 
For PS to CS transfer, the Session Transfer Number for Single Radio 
Voice Call Continuity (STN-SR) as described in TS 23.237 [407]. 
For CS to PS transfer, the Session Transfer Identifier for CS to PS 
Single Radio Voice Call Continuity (STI-rSR) as described in TS 
23.237 [407]. 

This field is only present if different from the Called Party Address 
parameter. 


List of Subscription Id 


Om 


Holds the public user identities of the served user 


List of Called Asserted Identity 


Oc 


The address or addresses of the final asserted identities. Present if 

the final asserted identities are available in the SIP 2xx response. 


Service Request Time Stamp 


Om 


This field contains the time stamp which indicates the time at which 
the service was requested. This parameter corresponds to SIP 

Request Timestamp. Present with Charging Data Request [Start] and 
Charging Data Request [Event]. 



ETSI 



3GPP TS 32.260 version 11.7.0 Release 11 



123 



ETSI TS 132 260 V1 1.7.0 (2013-04) 



Field 


Category 


Description 


Service Request Time Stamp Fraction 


Om 


This parameter contains the milliseconds fraction in relation to the 
Service Request Time Stamp. 


Service Delivery Start Time Stamp 


Om 


This field holds the time stamp reflecting either: successful session 
set-up, a delivery unrelated service, an unsuccessful session set-up 
and an unsuccessful session unrelated request. This parameter 
corresponds to SIP Response Timestamp. Present with Charging 
Data Request [Start] and Charging Data Request [Event]. 


Service Delivery Start Time Stamp 
Fraction 


Om 


This parameter contains the milliseconds fraction in relation to the 
Service Delivery Start Time Stamp. 


Service Delivery End Time Stamp 


Oc 


This field records the time at which the service delivery was 
terminated. It is Present only in SIP session related case. This 
parameter corresponds to SIP Request Timestamp. Present with 
Charging Data Request [Stop]. 


Service Delivery End Time Stamp 
Fraction 


Oc 


This parameter contains the milliseconds fraction in relation to the 
Service Delivery End Time Stamp. 


Record Opening Time 


Oc 


A time stamp reflecting the time the CDF opened this record. Present 

only in SIP session related case. 


Record Closure Time 


Om 


A Time stamp reflecting the time the CDF closed the record. 


Inter Operator Identifiers 


Oc 


1 1 1 1 Xl '1 L' X' .£ Xl 1 X 1 / ■ ■ X' 1 

Holds the identification of the home network (originating and 
terminating) if exchanged via SIP signalling, as recorded in the P- 
Charging-Vector header. 


Originating 101 


Oc 


This parameter corresponds to Orig-IOI header of the P-Charging- 
Vector defined in TS 24.229 [204]. 


Terminating 101 


Oc 


This parameter corresponds to Term-IOI header of the P-Charging- 
Vector defined in TS 24.229 [204]. 


Transit 101 List 


Oc 


This parameter corresponds to Transit-IOI List of the P-Charging- 

\/__j._,„ — __i ;~ TO nA oor\ rort*n 

Vector defined in TS 24.229 [204]. 


Local Record Sequence Number 


Om 


This field includes a unique record number created by this node. The 
number is allocated sequentially for each partial CDR (or whole CDR) 
including all CDR types. The number is unique within the CDF. 


Record Sequence Number 


Oc 


This field contains a running sequence number employed to link the 
partial records generated by the CDF for a particular session. 


Cause For Record Closing 


Om 


This field contains a reason for the close of the CDR. 


Incomplete CDR Indication 


Oc 


This field provides additional diagnostics when the CDF detects 
missing Charging Data Requests. 


IMS Charging Identifier 


Om 


This parameter holds the IMS charging identifier (ICID) as generated 
by the IMS node for the SIP session. 


List of Early SDP Media Components 


Oc 


This is a grouped field which may occur several times in one CDR. 
Each occurrence shall describe a change in the state (inactive/active 
or vice versa) of the media components negotiated during the SIP 
session establishment previously to the reception of a SIP final 
response to the initial SIP Invite. 

This field shall not be present if no media components are set to 
active before the final SIP session answer to the initial SIP Invite is 

received. 

This field can be present in either session or event CDRs. 


SDP Session Description 


Oc 


Holds the Session portion of SDP data exchanged in the above 
mentioned scenario, if available. 


SDP Type 


Om 


This parameter indicates if the SDP media component is an SDP 
offer or SDP answer. 


SDP Offer Timestamp 


Om 


This parameter contains the time of the SIP Request which conveys 
the bUr otter. 


SDP Answer Timestamp 


Om 


This parameter contains the time of the response to the SIP Request 
which conveys the SDP answer. 


SDP Media Components 


Om 


This is a grouped field comprising several sub-fields associated with 
one media component. Since several media components may exist 
for a session in parallel these sub-fields may occur several times. 


SDP Media Name 


Om 


This field holds the name of the media as available in the SDP data. 


SDP Media Description 


Om 


This field holds the attributes of the media as available in the SDP 
data. 
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Pategory 


Description 


Access Correlation ID 


Oc 


This parameter holds the charging identifier from the access network, 
consisting of either GPRS charging ID (GCID) which is generated by 
the GGSN for a GPRS PDP context, Charging Id which is generated 
by P-GW for IP-CAN bearer or the Access Networl< Charging 
Identifier Value which is generated by another type of access 
network. 

It is present only if received from the access network when PCC 
architecture is implemented. 


Media Initiator Flag 


Oc 


This field indicates if the called party has requested the session 
modification and it is present only if the initiator was the called party. 


List of SDP Media Components 


Oc 


This is a grouped field which may occur several times in one CDR. 

The first occurrence describes the initial session negotiation whilst 
the other would stem from session re-negotiations, including transfer 
CS to PS or PS to CS.. 

The field is present only in a SIP session related case. 
When the AS acts as B2BUA and OneChargingSession option 
applies, only SDP media components received by the AS are 
included, i.e those generated by the AS are not included. 


SDP Session Descnption 


Oc 


Holds the Session portion of the SDP data exchanged between the 
User Agents if available in the SIP transaction. 


SDP Type 


Om 


This parameter indicates if the SDP media component is an SDP 
offer or SDP answer. 


SIP Request Timestamp 


Oc 


This parameter contains the time of the SIP Request (usually a 
(Re)lnvite). This parameter corresponds to SIP Request Timestamp 
in Charging Data Request [Interim]. 


SIP Response Timestamp 


Oc 


This parameter contains appropriately the time of 200 OK 
acknowledging an INVITE or of ACK including an SDP answer. This 
parameter corresponds to SIP Response Timestamp in Charging 
Data Request [Interim]. 


SIP Request Timestamp Fraction 


Oc 


This parameter contains the milliseconds fraction in relation to the 

SIP Request Timestamp. 


SIP Response Timestamp 


Oc 


This parameter contains appropriately the time of 200 OK 
acknowledging an INVITE or of ACK including an SDP answer. This 
parameter corresponds to SIP Response Timestamp in Charging 
Data Request [Interim]. 


SDP Media Components 


Om 


This is a grouped field comprising several sub-fields associated with 
one media component. Since several media components may exist 

for a session in parallel these sub-fields may occur several times. 


SDP Media Name 


Om 


This field holds the name of the media as available in the SDP data. 


SDP Media Description 


Om 


This field holds the attributes of the media as available in the SDP 
data. 


Access Correlation ID 


Oc 


This parameter holds the charging identifier from the access network, 
consisting of either GPRS charging ID (GCID) which is generated by 
the GGSN for a GPRS PDP context, Charging Id which is generated 
by P-GW for IP-CAN bearer or the Access Network Charging 
Identifier Value which is generated by another type of access 
network. 

It is present only if received from the access network when PCC 
architecture is implemented. 


Media Initiator Flag 


Oc 


This field indicates if the called party has requested the session 
modification and it is present only if the initiator was the called party. 


GGSN Address 


Oc 


This parameter holds the control plane IP address of the GGSN that 
handles one or more media component(s) of a IMS session. 


Service Reason Return Code 


Om 


This parameter provides the returned SIP status code for the service 
request for the successful and failure case, 


Service Specific Info 


Oc 


This is a grouped field that contains service specific data if and as 
provided by an Application Server. It may occur several times in one 
CDR. 


Service Specific Data 


Om 


This sub-field of Service Specific Data holds the value of the Service 
Specific Data. 


Service Specific Type 


Om 


This sub-field of Service Specific Data holds the type of the Service 
Specific Data. 


List of Message Bodies 


Oc 


This grouped field comprising several sub-fields describing the data 
that may be conveyed end-to-end in the body of a SIP message. 
Since several message bodies may be exchanged via SIP-signalling, 
this grouped field may occur several times. 
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Field 


Category 


Description 


Content-Type 


Om 


This sub-field of Message Bodies holds the MIME type of the 
message body, Examples are: application/zip, image/gif, audio/mpeg, 
etc. 


Content-Disposition 


Oc 


This sub-field of Message Bodies holds the content disposition of the 
message body inside the SIP signalling, Content-disposition header 
field equal to render , indicates that the body part should be 
displayed or otherwise rendered to the user". Content disposition 
values are : session, render, inline, icon, alert, attachment, etc. 


Content-Length 


Om 


This sub-field of Message Bodies holds the size of the data of a 
message body in bytes. 


Originator 


Oc 


This sub-field of the "List of Message Bodies" indicates the 
originating party of the message body. 


Access Networl< Information 


Oc 


This field contains the content of the first available SIP P-header "P- 
Access-Network-lnfo" if available. 


List of Access Transfer Information 


Oc 


This field is a list of grouped field describing the subsequent CS to 
PS or PS to CS session transfers. 

Each other occurence comprises sub-fields describing the session 
transfer performed. 


Access Transfer Type 


Oc 


This field contains indication about the access transfer performed: 
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CS to PS, or PS to CS.This field is present only when transfer 
occurred. 


Access Network Information 


Oc 


This field holds the content of the SIP P-header "P-Access-Network- 
Info" from the INVITE requesting the transfer. 


Service Context Id 


Om 


Holds the context information to which the CDR belongs. The 
information is obtained from the Operation Token of the Charging 
Data Request message. 


IMS Communication Service ID 


Oc 


This field contains the IMS communication service identifier if 
received in the P-Asserted-Service header in the SIP request. 


Online Charging Flag 


OC 


This field indicates the Online Charging Request was sent based on 
the provided ECF address from the SIP P-header "P-Charging- 
Function-Addresses". 

NOTE: No proof that online charging action has been taken 


Real Time Tariff Information 


Oc 


This field holds the tariff/add-on charge received. 


Initial IMS Charging Identifier 


Oc 


This parameter holds the Initial IMS charging identifier (ICID) as 
generated by the IMS node for the initial SIP session created for IMS 
service continuity. 

This field is not used for the "OneChargingSession" option. 


User Location Info 


OC 


This field indicates details of where the UE is currently located (e.g. 
SAI, TAI, RAI, CGI, ECGI or access-specific user location 
information). 


MS Time Zone 


oc 


This field indicates the offset between universal time and local time in 
steps of 15 minutes of where the MS currently resides. 


From Address 


Om 


Contains the information from the SIP From header. 


IMS Visited Network Identifier 


Oc 


Contains the information from the SIP P-Visited-Network-ID header 
received in a REGISTER request. 


Record Extensions 


Oc 


A set of operator/manufacturer specific extensions to the record, 
conditioned upon existence of an extension. 



Editor's note; User Location Information and MS Time Zone to be updated after CTl stage 3 work is completed. 
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6.1.3.10 IBCF CDR Content 

The detailed description of the field is provided in TS 32.298 [51]. 



Table 6.1.3.10: Charging Data of IBCF CDR 



Field^^M 


Category 


Description 
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lUUI 1 LI 1 ICO LI Ic Ly [Jc; Ul 1 t:7LrUI U. 1 1 Ic fJCLI Cll 1 ICLCI lo Ucl 1 VcU 1 1 Ul 1 1 LI Ic 1 NUUC 1 U 1 lULIUI ICill Ly 

parameter. 


ndl Cll lisl 1 lloolLfl 1 




Xhic naramotor \n/hon nrocont inrlir'a+oc that informatinn from rotrancmittoH 

1 IMo [Jctldlllclci, vvllcll IJICocllL, IIIUIL-dLco ulctl lillUIIIIClllUII IIUlll iCLldllollllLLcU 

Chflrninn Data Rpniipcrtc; ha^; hppn iicprl in thi<^ CDR 


SIP Method 


Oc 


Specifies the SIP-method for which the CDR Is generated. Only available In 
session unrelated cases. 


P\/ont 




Thic fi^lH iH^ntifioc tho ^IP o\/ont nar'kario tn VA/hir'h th^ ^IP roniioct ic roforroH 

1 1 llo 1 IC7IU lUCI 1 LI 1 ItJO tllC oil CVCllL [JdUrxCiy C LU Vvl IIUI 1 LI IC Ol r I CLjUCOL lo 1 CiCl 1 CU. 


Expires Information 


Oc 


This field indicates the validity time of either the SIP message or its content, 

ucjJciiuiny Ul 1 11 Ic oir iiicLiiuu. 


Role of Node 


Om 


This field Indicates whether the IBCF Is serving the Originating or the Terminating 
party. 


iNoae Auaress 




This item holds the address of the node providing the information for the CDR. 
This may either be the IP address or the FQDN of the IMS node generating the 

intinn Hats 

CLLfLfUUI ILII ly UClLCt. 


Session ID 


Om 


The Session Identification. For a SIP session the Session-ID contains the SIP 
Call ID as defined In the Session Initiation Protocol RFC 3261 [404]. 


Session Priority 


Oc 


The field contains the priority of the session. 


List Of Calling Party 
Address 


Om 


The address or addresses (Public User ID or Public Service ID) of the party 
requesting a service or Initiating a session. In the case of no P-Asserted-ldentIfy 
is known, this list shall include a one Item with the value "unknown". 


Called Party Address 


Um 


In the context of an end-to-end SIP transaction this field holds the address of the 
party (Public User ID) to whom the SIP transaction is posted. 


Service Request Time 
Stamp 


Om 


This field contains the time stamp which indicates the time at which the service 
was requested. This parameter corresponds to SIP Request Timestamp. Present 
with Charging Data Request [Start] and Charging Data Request [Event]. 


Service Request Time 
Stamp Fraction 


Um 


This parameter contains the milliseconds fraction in relation to the Service 

Request Time Stamp. 


Service Delivery Start 
1 ime oTamp 


Um 


This field holds the time stamp reflecting either: successful session set-up, a 
delivery unrelated service, an unsuccessful session set-up and an unsuccessful 
session unrelated request. This parameter corresponds to SIP Response 

XimoctQmr\ Procont \A/ith Oharninn Plata Rom loct r^tartl anH Oharninn natQ 

1 II 1 iCOlCti 1 l|J. r 1 cod 11 VVIlll Ol icii y II ly L^dLd ncLjUCoL [OlCtI LJ Ctl lU Ol icti y II ly Uala. 

Request [Event]. 


otJi vioc LJtJiivtJiy oicii I 

Time Stamp Fraction 


^m 


Thic naramotor r^rintainc tho millicorrinrlc frar'tirin in rolatirin ir\ tho Qorv/ir'O 
iiiio [Jdidiiiclci OUi iLdiiio 11 Ic iiiiiiiocL>UiiUo ii dULiUi i ill i cidLiUi i LU Li ic Oci viuc 

Delivery Start Time Stamp. 


^orv/ir'o Ploli\/or\/ FnH 
oci viLfC i_/ciivciy lu 

Time Stamp 


yJC 


Thic fiolH rorrirHc tho timo at lA/hir'h tho corx/ir'o Holi\/or\/ \A/ac torminatoH It ic 

1 1 Jlo 1 ICIU 1 CLfUl Llo IIIC Lllllc ClL WIIIUII LIIC ocl VILrC UCll VCl y Wclo ICI 1 1 III laLcU. 1 L lo 

Present only in SIP session related case. This parameter corresponds to SIP 
Rpniipct Timp*^taiTin Prp*^pnt with Oharninn Data Rpniip<^t rStnnl 

1 ICUUCOL 1 IIIICOLCllIlky- 1 ICOCIIl VVILII V_/l IC4,I y ' 'M 1— 'ULU I ICUUCOl \\J LWk^J ■ 


Service Delivery End 
Time Stamp Fraction 


Oc 


This parameter contains the milliseconds fraction in relation to the Service 
Delivery End Time Stamp. 


liCLrUl U wlJd III lU 1 II 1 ic 


yJC 


A timo ctamn roflor'tinn tho timo tho OPIP nnonoH thic rorr^rH Procont r»nl\/ in ^IP 

r\ Lll 1 IC oLCtI MU 1 Cl ICUIII lU LIIC LI IIIC LIIC O LJ 1 UIJCl ICU LI Ho 1 CUUI VJ. niCoClll Ulliy III OIn 

session related case. 


RorrirH f^lnciiro Timo 
ric;L>uiu oiUoUic; iiiiic; 




A Timo ctamn roflor'tinn tho timo tho (^PlF nlocorl tho rorrirrl 
r\ 1 II 1 Ic oLdI 1I|J IcIlcULHIL) Lllc Lllllc lllc \jlJi UlUocU 11 ic 1 cUUI U 


Inter Operator Identifiers 


Oc 


Holds the identification of the home networl^ (originating and terminating) if 
PYPhannpH via 5^IP <^innallinn a^ rpforHprl in thp P-Oh^('ninn-\/f^cfn(' hf^^rif^r 

CAV^I Idii^CU vIClvJII Oi^iiCliiiii^, do 1 CUUI UCU ill LIIC / \yi ICll yii /y V COiU/ 1 /CClUC/ . 


Originating 101 


Oc 


This parameter corresponds to Orig-IOI header of the P-Charging-Vector defined 
In TS 24.229 [204]. 


Terminating 101 


Oc 


This parameter corresponds to Term-IOI header of the P-Charglng-Vector 
defined In TS 24.229 [204]. 


Transit 101 List 


Oc 


This parameter corresponds to Translt-IOI List of the P-Charglng-Vector defined 
in TS 24.229 [204]. 


Local Record Sequence 
Number 


Om 


This field Includes a unique record number created by this node. The number Is 
allocated sequentially for each partial CDR (or whole CDR) Including all CDR 
types. The number Is unique within the CDF. 


Record Sequence 
Number 


Oc 


This field contains a running sequence number employed to link the partial 
records generated by the CDF for a particular session. 


Cause For Record 
Closing 


Om 


This field contains a reason for the close of the CDR. 



ETSI 



3GPP TS 32.260 version 11.7.0 Release 11 



127 



ETSI TS 132 260 V1 1.7.0 (2013-04) 



Field 


Category 


Description 


Incomplete CDR 
Indication 


Oc 


This field provides additional diagnostics when the CDF detects missing Charging 
Data Requests. 


IMS Charging Identifier 


Om 


This parameter holds the IMS charging identifier (ICID) as generated by the IMS 
node for the SIP session. 


List of Early SDP Media 
Components 


Oc 


This is a grouped field which may occur several times in one CDR. 

Each occurrence shall describe a change in the state (inactive/active or vice 

versa) of the media components negotiated during the SIP session establishment 

previously to the reception of a SIP final response to the initial SIP Invite. 

This field shall not be present if no media components are set to active before the 

final SIP session answer to the initial SIP Invite is received. 

This field can be present in either session or event CDRs. 


SDP Session 
Description 


Oc 


Holds the Session portion of SDP data exchanged in the above mentioned 
scenario, if available. 


SDP Type 


Om 


This parameter indicates if the SDP media component is an SDP offer or SDP 
answer. 


SDP Offer Timestamp 


Om 


This parameter contains the time of the SIP Request which conveys the SDP 
Otter. 


SDP Answer 
Timestamp 


Om 


This parameter contains the time of the response to the SIP Request which 
conveys the SDP answer. 


SDP Media 
Components 


Om 


This is a grouped field comprising several sub-fields associated with one media 
component. Since several media components may exist for a session in parallel 

these sub-fields may occur several times. 


SDP Media Name 


Om 


This field holds the name of the media as available in the SDP data. 


SDP Media 
Description 


Om 


This field holds the attributes of the media as available in the SDP data. 


Media Initiator Flag 


Oc 


This field indicates if the called party has requested the session modification and 

It IS present only if the initiator was the called party. 


List of SDP Media 
Components 


Oc 


This is a grouped field which may occur several times in one CDR. The first 
occurrence describes the initial session negotiation whilst the other would stem 
from session re-negotiations. 
The field is present only in a SIP session related case. 


SDP Session 
Description 


Oc 


Holds the Session portion of the SDP data exchanged between the User Agents 
if available in the SIP transaction. 


SDP Type 


Om 


This parameter indicates if the SDP media component is an SDP offer or SDP 
answer. 


SIP Request 
Timestamp 


Oc 


This parameter contains the time of the SIP Request (usually a (Re)lnvite). This 
parameter corresponds to SIP Request Timestamp in Charging Data Request 
[Interim]. 


SIP Response 
Timestamp 


Oc 


This parameter contains appropriately the time of 200 OK acknowledging an 
INVITE or of ACK including an SDP answer. This parameter corresponds to SIP 
Response Timestamp in Charging Data Request [Interim]. 


SIP Request 
Timestamp Fraction 


Oc 


-T" I" i 1" l| "11" If J." Ix" L Ll 1 1— * 1— i 1 

This parameter contains the milliseconds fraction in relation to the SIP Request 
Timestamp. 


SIP Response 
Timestamp Fraction 


Oc 


This parameter contains the milliseconds fraction in relation to the SIP Response 

Timestamp. 


SDP Media 
Components 


Om 


This is a grouped field comprising several sub-fields associated with one media 
component. Since several media components may exist for a session in parallel 
these sub-fields may occur several times. 


bUr Media Name 


Om 


This field holds the name of the media as available in the SDP data. 


SDP Media 
Description 


Om 


This field holds the attributes of the media as available in the SDP data. 


Local GW Inserted 
Indication 


Oc 


This field indicates whether the local TrGW is inserted or not, for the media 
component included in SDP answer, if available. 


IP Realm Default 

Indication 


Oc 


This field indicates whether the User Plane IP realm associated to the media 
component included in SDP answer, is the Default IP realm or not, if available. 


Transcoder 
Inserted Indication 


Oc 


This field indicates whether a transcoder is inserted or not, for the media 
component included in the SDP answer, if available. 


Media Initiator Flag 


Oc 


This field indicates if the called party has requested the session modification and 

it is present only if the initiator was the called party. 


Service Reason Return 
Code 


Om 


This parameter provides the returned SIP status code for the service request for 
the successful and failure case, 


List of Message Bodies 


OC 


This grouped field comprising several sub-fields describing the data that may be 
conveyed end-to-end in the body of a SIP message. Since several message 
bodies may be exchanged via SIP-signalling, this grouped field may occur 
several times. 
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rieio 


Category 


Description 


Content-Type 


OIVl 


This sub-field of Message Bodies holds the MIIVIE type of the message body, 
Examples are: application/zip, image/gif, audio/mpeg, etc. 


Content-Disposition 


oc 


This sub-field of Message Bodies holds the content disposition of the message 
body inside the SIP signalling, Content-disposition header field equal to "render", 
indicates that "the body part should be displayed or otherwise rendered to the 
user". Content disposition values are : session, render, inline, icon, alert, 
attachment, etc. 


Content-Length 


OIVl 


This sub-field of Message Bodies holds the size of the data of a message body in 
bytes. 


Originator 


oc 


This sub-field of the "List of Message Bodies" indicates the originating party of 
the message body. 


Access Networl< 
Information 


Oc 


This field contains the content of the SIP P-header "P-Access-Network-lnfo" if 
available. 


IIVIS Communication 
Service Id 


Oc 


Contains the identifier for the type of communication service the IMS is currently 
providing for the session. 


Qpruipp r^nntPYt IH 




HnlrlQ thp pnntPYt infnrmptinn tn whiph thp ODR hplnnn*^ Thp infnrrnptinn 1*? 

1 lUIUO LIIC V^UIILOvl IIIIWIIIICILIWII L\J VVIIIV^II Lll^ \J I I k>dv./IIUO. 1 IIC IIIIV./IIIICILIV./II lO 

obtained from the Operation Token of the Charging Data Request message. 


Real Time Tariff 
Information 


Oc 


This field holds the tariff/add-on charge received. 


User Location Info 


OC 


This field indicates details of where the UE is currently located (e.g. SAI, TAI, 
RAI, CGI, ECGI or access-specific user location information). 


IVIS Time Zone 


OC 


This field indicates the offset between universal time and local time in steps of 15 
minutes of where the MS currently resides. 








NINII 1 nfnrmatirtn 

ININI llllUlllldLIUII 


Or 


1 lllo ^IUU|Jc;U llc;iU \j\J \ ll|Jlloiii^ oc;vUiCll oUU IIUIUo llUiUo llMUiiilCiLiUii ClUUU L Li ic; 1 N 1 N 1 

used for interconnection and roaming. This field may occur more than once in a 
CDR e.g. when routing capability in support of transit is collocated with the IBCF. 


Session Direction 


Oc 


This field indicates whether the NNI is used for an inbound or outbound service 
request on the control plane in case of interconnection and roaming. 


NNI Type 


Oc 


This field indicates whether the type of used NNI is non-roaming, roaming with 
loopback routing, or roaming without loopback routing. 


Relationship IVIode 


Oc 


This field indicates whether the other functional entity (contact point of the 
neighbouring network) is regarded as part of the same trust domain. 


Neighbour Node 
Address 


Oc 


This field holds the control plane IP address of the neighbouring network contact 
point that handles the service request in case of interconnection and roaming. 


From Address 


Om 


Contains the information from the SIP From header. 


Record Extensions 


Oc 


A set of operator/manufacturer specific extensions to the record, conditioned 
upon existence of an extension. 



Editor's note: User Location Information and MS Time Zone to be updated after CTl stage 3 work is completed. 
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6.1 .3.1 1 E-CSCF CDR Content 

The detailed description of the field is provided in TS 32.298 [51]. 



Table 6.1 .3.1 1 : Charging Data of E-CSCF CDR 



Record Type 


Category 

M 


Descri|}tiQn.^^^^^^^^^^^^M 

Identifies the type of record. The parameter is derived from the 
Node functionality parameter. 


Retransmission 


Oc 


This parameter, when present, indicates that information from 
retransmitted Charging Data Requests has been used in this 
CDR 


SIP Metliod 


Oc 


Specifies the SIP-method for which the CDR is generated. Only 
available in session unrelated cases. 


Event 


Oc 


This field identifies the SIP event pacl<age to which the SIP 

request is referred. 


Expires Information 


Oc 


This field indicates the validity time of either the SIP message 
or its content, depending on the SIP method. 


Role of Node 


Om 


This field indicates whether the E-CSCF is serving the 
Originating or the Terminating party. 


Node Address 


Om 


This item holds the address of the node providing the 
information for the CDR. This may either be the IP address or 
the FQDN of the IMS node generating the accounting data. 


Session ID 


Om 


The Session identification. For a SIP session the Session-ID 
contains the SIP Call ID as defined in the Session Initiation 
Protocol RFC 3261 [404]. 


Session Priority 


Oc 


The field contains the priority of the session. 


List Of Calling Party Address 


Om 


The address or addresses (Public User ID or Public Service ID) 
of the party requesting a service or initiating a session. In case 
no P-Asserted-ldentity is known, this list shall include one item 
with the value "unl<nown". 


List of Associated URI 


Oc 


The list of non-barred public user identities (SIP URIs and/or 
TEL URIs) associated to the public user identity under 
registration. 


Called Party Address 


Om 


For SIP transactions, this field holds the address of the party 
(Public User ID or Public Service ID) to whom the SIP 
transaction is posted. It could be in the format of a SIP URI, a 
TEL URI or a URN 


Requested Party Address 


Oc 


For SIP transactions this field holds the address of the party 
(Public User ID or Public Service ID) to whom the SIP 
transaction was originally posted. 

This field is only present if different from the Called Party 
Address parameter. 


Number Portability routing information 


Oc 


This field includes information on number portability after 
DNS/ENUM request from E-CSCF in the calling user's home 
network. 


Carrier Select routing information 


Oc 


This field includes information on carrier select after 
DNS/ENUM request from E-CSCF in the calling user's home 
network. 


List of Called Asserted Identity 


Oc 


The address or addresses of the final asserted identities. 
Present if the final asserted identities are available in the SIP 
2xx response. 


Private User ID 


Oc 


Holds the used private user identity of the served party 

according to RFC2486 [405] if available. 


List of Subscription id 


Oc 


Holds the public user identities of the served user 


Service Request Time Stamp 


Om 


This field contains the time stamp, which indicates the time at 
which the service was requested. 


Service Request Time Stamp Fraction 


Om 


This parameter contains the milliseconds fraction in relation to 

the Service Request Time Stamp. 


Service Delivery Start Time Stamp 


Om 


This field holds the time stamp reflecting either: successful 
session set-up, a delivery unrelated service, an unsuccessful 
session set-up and an unsuccessful session unrelated request. 


Service Delivery Start Time Stamp Fraction 


Om 


This parameter contains the milliseconds fraction in relation to 
the Service Delivery Start Time Stamp. 
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rieia ^^^^H 


Category 


Description 


Service Delivery End Time Stamp 


Oc 


This field records the time at which the service delivery was 
terminated. It is Present only in SIP session related case. 


Service Delivery End Time Stamp Fraction 


Oc 


This parameter contains the milliseconds fraction in relation to 
ine oervice ueiivery tno i ime otamp. 


Record Opening Time 


Oc 


A time stamp reflecting the time the CDF opened this record. 
Present only in SIP session related case. 


Record Closure Time 


Om 


A Time stamp reflecting the time the CDF closed the record. 


Application Servers Information 


Oc 


This a grouped CDR field containing the fields: "Application 
Server Involved" and "Application Provided Called Parties". 


Application Servers Involved 


Oc 


till il A *^ \ ■ 1 !.'£' 1 1 J.I 1 r-\ 1 1 1— * 1 

Holds the ASs (if any) identified by the SIP URIs. 


Application Provided Called Parties 


Oc 


Holds a list of the Called Party Address(es), if the address(es) 
are determined by an AS (SIP URI, E.164...). 


List of Inter Operator Identifiers 


Oc 


Holds the identification of the home network (originating and 
terminating) if exchanged via SIP signalling, as recorded in the 
P-Charging-Vector header. This grouped field may occur 
several times in one CDR. 


Originating 101 


Oc 


This parameter corresponds to Orig-IOI header of the P- 
Charging-Vector defined in TS 24.229 [204]. 


Terminating 101 


Oc 


This parameter corresponds to Term-IOI header of the P- 
Charging-Vector defined in TS 24.229 [204]. 


Local Record Sequence Number 


Om 


This field Includes a unique record number created by E-CSCF. 

^ni 1 ' II X 1 X' II X 1 X' 1 r~\ r~» / 

The number is allocated sequentially for each partial CDR (or 
whole CDR) including all CDR types. The number is unique 
Within the OUr. 


Record Sequence Number 


Oc 


This field contains a running sequence number employed to 
link the partial records generated by the CDF for a particular 

session. 


Cause For Record Closing 


Om 


This field contains a reason for the close of the CDR. 


Incomplete GDR Indication 


Oc 


This field provides additional diagnostics when the CDF detects 
missing Charging Data Requests. 


IMS Charging Identifier 


Om 


This parameter holds the IMS charging Identifier (ICID) as 
generated by the IMS node for the SIP session. 


List of Early SDP Media Components 


Oc 


This is a grouped field which may occur several times in one 
CDR. 

Each occurrence shall describe a change in the state 
(inactive/active or vice versa) of the media components 
negotiated during the SIP session establishment previously to 
the reception of a SIP final response to the initial SIP Invite. 

This field shall not be present if no media components are set 
to active before the final SIP session answer to the initial SIP 
Invite is received. 

This field can be present in either session or event CDRs. 






SDP Session Description 


Oc 


Holds the Session portion of SDP data exchanged in the above 

mentioned scenario, if available. 


SDP Type 


Om 


This parameter indicates if the SDP media component is an 
SDP offer or SDP answer. 


SDP Offer Timestamp 


Om 


This parameter contains the time of the SIP Request which 
conveys the SDP offer. 


SDP Answer Timestamp 


Om 


This parameter contains the time of the response to the SIP 
Request which conveys the SDP answer. 


SDP Media Components 


Om 


This is a grouped field comprising several sub-fields associated 
with one media component. Since several media components 
may exist for a session in parallel these sub-fields may occur 
several times. 


SDP Media Name 


Om 


This field holds the name of the media as available in the SDP 

data. 


SDP Media Description 


Om 


This field holds the attributes of the media as available in the 
SDP data. 


Access Correlation ID 


Oc 


This parameter holds the charging identifier from the access 
network, consisting of either GPRS charging ID (GCID) which is 
generated by the GGSN for a GPRS PDP context, Charging Id 
which is generated by P-GW for IP-CAN bearer or the Access 
Network Charging Identifier Value which is generated by 
another type of access network. 

It is present only if received from the access network when 
PCC architecture is implemented. 
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Field'^^^^^^V 


Category 


Description 


Media Initiator Flag 


Oc 


This field indicates if the called party has requested the session 
modification and it is present only if the initiator was the called 
party. 


List of SDP Media Components 


Oc 


This is a grouped field which may occur several times in one 
CDR. The first occurrence describes the initial SIP session 
negotiation whilst the other would stem from session re- 
negotiations. 

The field is present only in a SIP session related case. 


SDP Session Description 


Oc 


Holds the Session portion of the SDP data exchanged between 
the User Agents if available in the SIP transaction. 


SDP Type 


Om 


This parameter indicates if the SDP media component is an 
bUr Otter or our answer. 


SIP Request Timestamp 


Oc 


This parameter contains the time of the SIP Request (usually a 
(Ke)lnvite). 


SIP Response Timestamp 


Oc 


This parameter contains appropriately the time of 200 OK 

acknowledging an INVITE or of ACK including an SDP answer. 


SIP Request Timestamp Fraction 


Oc 


This parameter contains the milliseconds fraction in relation to 
the SIP Request Timestamp. 


SIP Response Timestamp Fraction 


Oc 


This parameter contains the milliseconds fraction in relation to 
the SIP Response Timestamp. 


SDP Media Components 


Om 


This is a grouped field comprising several sub-fields associated 
with one media component. Since several media components 
may exist for a session in parallel these sub-fields may occur 
several times. 


SDP Media Name 


Om 


This field holds the name of the media as available in the SDP 
data. 


SDP Media Description 


Om 


This field holds the attributes of the media as available in the 
SDP data. 


Access Correlation ID 


Oc 


This parameter holds the charging identifier from the access 
network, consisting of either GPRS charging ID (GCID) which is 
generated by the GGSN for a GPRS PDP context, Charging Id 
which is generated by P-GW for IP-CAN bearer or the Access 
Network Charging Identifier Value which is generated by 
another type of access network. 

It is present only if received from the access network when 
PCC architecture is implemented. 


Media Initiator Flag 


Oc 


This field indicates if the called party has requested the session 
modification and it is present only if the initiator was the called 

party. 


GGSN Address 


Oc 


This parameter holds the control plane IP address of the GGSN 
that handles one or more media component(s) of an IMS 
session. 


Service Reason Return Code 


Om 


This parameter provides the returned SIP status code for the 
service request for the successful and failure case. 


List of Message Bodies 


Oc 


This grouped field comprising several sub-fields describing the 
data that may be conveyed end-to-end in the body of a SIP 
message. Since several message bodies may be exchanged 
via SIP-signalling, this grouped field may occur several times. 


Content-Type 


Om 


This sub-field of Message Bodies holds the MIME type of the 
message body, Examples are: application/zip, image/gif, 

audio/mpeg, etc. 


Content-Disposition 


Oc 


This sub-field of Message Bodies holds the content disposition 
of the message body inside the SIP signalling. Content- 
disposition header field equal to "render", indicates that "the 
body part should be displayed or otherwise rendered to the 
user". Content disposition values are: session, render, inline, 
icon, alert, attachment, etc. 


Content-Length 


Om 


This sub-field of Message Bodies holds the size of the data of a 
message body in bytes. 


Originator 


Oc 


This sub-field of the "List of Message Bodies" indicates the 
originating party of the message body. 


Access Network Information 


Oc 


This field contains the content of the SIP P-header "P-Access- 
Network-lnfo" if available. 
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Field 


Category 


Description 


Service Context Id 


Om 


Holds the context information to which the CDR belongs. The 
information is obtained from the Operation Token of the 
Charging Data Request message. 


IMf^ ("Inmmi inir^tinn f^pruirp ID 

1 1 vl \_f 1 II 1 ILII IIOCILIV^I 1 V ' 1 V 1 LJ 


Or 


ThiQ fiplH rnntain'^ thp IM.^ rnmmiiniP3tinn "^pruirp iHpntifipr if 

received in the P-Asserted-Service header in the SIP request. 


User Location Info 


oc 


This field indicates details of where the UE is currently located 
(e.g. SAI, TAI, RAI, CGI, ECGI or access-specific user location 
information). 


MS Time Zone 


oc 


This field indicates the offset between universal time and local 
time in steps of 15 minutes of where the MS currently resides. 


From Address 


Om 


Contains the information from the SIP From header. 


Record Extensions 


Oc 


A set of operator/manufacturer specific extensions to the 
record, conditioned upon existence of an extension. 



Editor's note: The completeness of all parameters for the E-CSCF CDR is ffs. 

Editor's note: User Location Information and MS Time Zone to be updated after CTl stage 3 work is completed. 
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6.1.3.12 TRF CDR Content 

The detailed description of the field is provided in TS 32.298 [51]. 



Table 6.1.3.12: Charging Data of TRF CDR 





Cateqorv 




Record Type 


M 


Identifies the type of record. Tfie parameter is derived 
from the Node functionality parameter. 


Retransmission 


Oc 


This parameter, when present, indicates that information 
from retransmitted Charging Data Requests has been 
used in this CDR. 


SIP IVIethod 


Oc 


Specifies the SIP-method for which the CDR is generated. 
Only available in session unrelated cases. 


Event 


Oc 


This field identifies the SIP event package to which the 
SIP request is referred. 


Expires Information 


Oc 


This field indicates the validity time of either the SIP 
message or its content, depending on the SIP method. 


Role of Node 


Om 


This field indicates whether the TRF is serving the 
Originating or the Terminating party. 


Node Address 


Om 


This item holds the address of the node providing the 
information for the CDR. This may either be the IP 
address or the PGDN of the IMS node generating the 
accounting data. 


Session ID 


Om 


The Session identification. For a SIP session the Session- 
ID contains the SIP Call ID as defined in the Session 
Initiation Protocol RFC 3261 [404]. 


Session Priority 


Oc 


The field contains the priority of the session. 


List Of Calling Party Address 


Om 


The address or addresses (Public User ID or Public 
Service ID) of the party requesting a service or initiating a 
session. 


Called Party Address 


Om 


In the context of an end-to-end SIP transaction this field 
holds the address of the party (Public User ID) to whom 
the SIP transaction is posted. 


List of Called Asserted Identity 


Oc 


The address or addresses of the final asserted identities. 

Present if the final asserted identities are available in the 
SIP 2xx response. 


Requested Party Address 


Oc 


For SIP transactions this field holds the address of the 
party (Public User ID or Public Service ID) to whom the 
SIP transaction was originally posted. 
This field is only present if different from the Called Party 
Address parameter. 


Number Portability routing information 


Oc 


This field includes information on number portability after 
DNS/ENUM request from the TRF. 


Carrier Select routing information 


Oc 


This field includes information on number portability after 
DNS/ENUM request from the TRF. 


Service Request Time Stamp 


Om 


This field contains the time stamp which indicates the time 
at which the service was requested. This parameter 
corresponds to SIP Request Timestamp. Present with 
Charging Data Request [Start] and Charging Data 
Request [Event]. 


Service Request Time Stamp Fraction 


Om 


This parameter contains the milliseconds fraction in 
relation to the Service Request Time Stamp. 


Service Delivery Start Time Stamp 


Om 


This field holds the time stamp reflecting either: 
successful session set-up, a delivery unrelated service, an 
unsuccessful session set-up and an unsuccessful session 
unrelated request. This parameter corresponds to SIP 
Response Timestamp. Present with Charging Data 
Request [Start] and Charging Data Request [Event]. 


Service Delivery Start Time Stamp Fraction 


Om 


This parameter contains the milliseconds fraction in 
relation to the Service Delivery Start Time Stamp. 


Service Delivery End Time Stamp 


Oc 


This field records the time at which the service delivery 
was terminated. It is Present only in SIP session related 
case. This parameter corresponds to SIP Request 
Timestamp. Present with Charging Data Request [Stop]. 
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rieiu 


Category 


Description 


Service Delivery End Time Stamp Fraction 


Oc 


This parameter contains the milliseconds fraction in 
relation to the Service Delivery End Time Stamp. 


Record Opening Time 


Oc 


A time stamp reflecting the time the CDF opened this 
record. Present only in SIP session related case. 


Record Closure Time 


Om 


A Time stamp reflecting the time the CDF closed the 

record 


Application Servers Information 


Oc 


This a grouped CDR field containing the fields: 
"Application Server Involved" and "Application Provided 
Called Parties". 


Application Servers Involved 


Oc 
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Holds the ASs (if any) identified by the SIP URIs. 


Application Provided Called Parties 


Oc 


Holds a list of the Called Party Address{es), if the 
address(es) are determined by an AS (SIP URI, E.164...). 


Inter Operator Identifiers 


Oc 


Holds the identification of the home network (originating 
and terminating) if exchanged via SIP signalling, as 
recorded in the P-Charging-Vector header. This grouped 
field may occur several times in one CDR. 


Originating 101 


Oc 


This parameter corresponds to Ong-IOI header of the P- 
Charging-Vector defined in TS 24.229 [204]. 


Terminating 101 


Oc 


This parameter corresponds to Term-IOI header of the P- 
Charging-Vector defined in TS 24.229 [204]. 


Transit 10! List 


Oc 


This parameter corresponds to Transit-IOI List of the P- 
Charging-Vector defined in TS 24.229 [204]. This field 
may occur several times in one CDR. 


Local Record Sequence Number 


Om 


This field includes a unique record number created by this 

i Tl l_ ' 11 X 1 x' 11 .£ 1 

node. The number is allocated sequentially for each 
partial CDR (or whole CDR) including all CDR types. The 

number is unique within the CDF. 


Record Sequence Number 


Oc 


This field contains a running sequence number employed 
to link the partial records generated by the CDF for a 
particular session. 


Cause For Record Closing 


Om 


This field contains a reason for the close of the CDR. 


Incomplete CDR Indication 


Oc 


This field provides additional diagnostics when the CDF 
detects missing Charging Data Requests. 


IMS Charging Identifier 


Om 


This parameter holds the IMS charging identifier (ICID) as 
generated by the IMS node for the SIP session. 


List of Early SDP Media Components 


Oc 


This is a grouped field which may occur several times in 
one CDR. 

Each occurrence shall describe a change in the state 
(inactive/active or vice versa) of the media components 
negotiated during the SIP session establishment 
previously to the reception of a SIP final response to the 
initial SIP Invite. 

This field shall not be present if no media components are 
set to active before the final SIP session answer to the 
initial SIP Invite is received. 

This field can be present in either session or event CDRs. 


SDP Session Description 


Oc 


Holds the Session portion of SDP data exchanged in the 
above mentioned scenario, if available. 


SDP Type 


Om 


This parameter indicates if the SDP media component is 
an SDP offer or SDP answer. 


SDP Offer Timestamp 


Om 


This parameter contains the time of the SIP Request 
which conveys the SDP offer. 


SDP Answer Timestamp 


Om 


This parameter contains the time of the response to the 
SIP Request which conveys the SDP answer. 


SDP Media Components 


Om 


This is a grouped field comprising several sub-fields 
associated with one media component. Since several 
media components may exist for a session in parallel 
these sub-fields may occur several times. 


SDP Media Name 


Om 


This field holds the name of the media as available in the 
SDP data. 


SDP Media Description 


Om 


This field holds the attributes of the media as available in 
the SDP data. 


Media Initiator Flag 


Oc 


This field indicates if the called party has requested the 
session modification and it is present only if the initiator 
was the called party. 
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^Bteqory 


Description 


List of SDP Media Components 


Oc 


This is a grouped field which may occur several times in 
one CDR. The first occurrence describes the initial 
session negotiation whilst the other would stem from 
session re-negotiations. 

The field is present only in a SIP session related case. 


SDP Session Description 


Oc 


Holds the Session portion of the SDP data exchanged 
between the User Agents if available in the SIP 
transaction. 


SDP Type 


Om 


This parameter indicates if the SDP media component is 
an SDP offer or SDP answer. 


SIP Request Timestamp 


Oc 


This parameter contains the time of the SIP Request 

(usually a (Re)lnvite). This parameter corresponds to SIP 
Request Timestamp in Charging Data Request [Interim]. 


SIP Response Timestamp 


Oc 


This parameter contains appropriately the time of 200 OK 
acknowledging an INVITE or of ACK including an SDP 
answer. This parameter corresponds to SIP Response 

Timestamp in Charging Data Request [Interim]. 


SIP Request Timestamp Fraction 


Oc 


This parameter contains the milliseconds fraction in 
relation to the SIP Request Timestamp. 


SIP Response Timestamp Fraction 


Oc 


This parameter contains the milliseconds fraction in 
relation to the SIP Response Timestamp. 


SDP Media Components 


Om 


This is a grouped field comprising several sub-fields 
associated with one media component. Since several 
media components may exist for a session in parallel 
these sub-fields may occur several times. 


SDP Media Name 


Om 


This field holds the name of the media as available in the 
SDP data. 


SDP Media Descnption 


Om 
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This field holds the attnbutes of the media as available in 

the SDP data. 


Media Initiator Flag 


Oc 


This field indicates if the called party has requested the 
session modification and it is present only if the initiator 
was the called party. 


Service Reason Return Code 


Om 


This parameter provides the returned SIP status code for 

the service request for the successful and failure case, 


List of Message Bodies 


OC 


This grouped field comprising several sub-fields 
describing the data that may be conveyed end-to-end in 
the body of a SIP message. Since several message 
bodies may be exchanged via SIP-signalling, this grouped 
field may occur several times. 


Content-Type 


OM 


This sub-field of Message Bodies holds the MIME type of 
the message body, Examples are: application/zip, 
image/gif, audio/mpeg, etc. 


Content-Disposition 


OC 


This sub-field of Message Bodies holds the content 
disposition of the message body inside the SIP signalling, 
Content-disposition header field equal to "render", 
indicates that "the body part should be displayed or 
otherwise rendered to the user". Content disposition 
values are : session, render, inline, icon, alert, 
attachment, etc. 


Content-Length 


OM 


This sub-field of Message Bodies holds the size of the 
data of a message body in bytes. 


Originator 


OC 


This sub-field of the "List of Message Bodies" indicates 
the originating party of the message body. 


IMS Communication Service Id 


Oc 


Contains the identifier for the type of communication 
service the IMS is currently providing for the session. 


Service Context Id 


Om 


Holds the context information to which the CDR belongs. 
The information is obtained from the Operation Token of 
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Real Time Tariff Information 


Oc 


This field holds the tariff/add-on charge received. 


User Location Info 


OC 


This field indicates details of where the UE is currently 
located (e.g. SAI, TAI, RAI, CGI, ECGI or access-specific 
user location information). 


MS Time Zone 


OC 


This field indicates the offset between universal time and 
local time in steps of 1 5 minutes of where the MS 
currently resides. 


Record Extensions 


Oc 


A set of operator/manufacturer specific extensions to the 
record, conditioned upon existence of an extension. 
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Description 


NNI Information 


Oc 


This grouped field comprising several sub-fields holds 
information about the NNI used for interconnection and 
roaming. This field may occur more than once in a CDR 
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collocated with the TRF. 


NNI Type 


Oc 


This field indicates whether the type of used NNI is non- 
roaming, roaming with loopback routing, or roaming 
without loopback routing. 
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6.1.3.13 ATCF CDR Content 

The detailed description of the field is provided in TS 32.298 [51]. 



Table 6.1.3.13: Charging Data of ATCF CDR 



Field 


Category 


Description 


Record Type 


M 


Identifies the type of record. The parameter is derived from the Node 
functionality parameter. 


Retransmission 


Oc 


This parameter, when present, indicates that information from 
retransmitted Charging Data Requests has been used in this CDR 


SIP IVIettiod 


Oc 


Specifies the SIP-method for which the CDR is generated. Only 
available in session unrelated cases. 


Event 


Oc 


This field identifies the SIP event package to which the SIP request is 
referred. 


Expires Information 


Oc 


This field indicates the validity time of either the SIP message or its 
content, depending on the SIP method. 


Role of Node 


Om 


This field indicates whether the ATCF is serving the Originating or the 
Terminating party. 


Node Address 


Om 


This item holds the address of the node providing the information for 
the CDR. This may either be the IP address or the FQDN of the IMS 
node generating the accounting data. 


Session ID 


Om 


The Session identification. For a SIP session the Session-ID contains 
the SIP Call ID as defined in the Session Initiation Protocol RFC 
3261 [404]. The incoming session is identified , except for the 
"OneChargingSession" option, where it contains either the incoming 
or outgoing dialog SIP Call Id involved during IMS session setup. 


Session Priority 


Oc 


The field contains the priority of the session. 


List Of Calling Party Address 


Om 


The address or addresses (Public User ID or Public Service ID, 
Correlation MSISDN) of the party requesting a service or initiating a 
session. In the case of no P-Asserted-ldentify is known, this list shall 
include one item with the value "unknown". 


Called Party Address 


Om 


For SIP transactions, except for registration, this field holds the 
address of the party (Public User ID or Public Service ID) to whom 
the SIP transaction is posted. 

For registration transactions, this field holds the Public User ID under 
registration. 


List of Requested Party Address 


Oc 


This field is a list of Requested Party Address. 
Each occurrence contains: 

For SIP transactions, the address of the party (Public User ID or 
Public Service ID) to whom the SIP transaction was originally posted. 
For PS to CS transfer, the Session Transfer Number for Single Radio 
Voice Call Continuity (STN-SR) as described in TS 23.237 [407]. 
For CS to PS transfer, the Session Transfer Identifier for CS to PS 
Single Radio Voice Call Continuity (STI-rSR) as described in TS 
23.237 [407]. 


List of Subscription Id 


Om 


Holds the public user identities of the served user 


List of Called Asserted Identity 


Oc 


The address or addresses of the final asserted identities. Present if 
the final asserted identities are available in the SIP 2xx response. 


Service Request Time Stamp 


Om 


This field contains the time stamp which indicates the time at which 
the service was requested. This parameter corresponds to SIP 
Request Timestamp. Present with Charging Data Request [Start] and 
Charging Data Request [Event]. 


Service Request Time Stamp Fraction 


Om 


This parameter contains the milliseconds fraction in relation to the 
Service Request Time Stamp. 


Service Delivery Start Time Stamp 


Om 


This field holds the time stamp reflecting either: successful session 
set-up, a delivery unrelated service, an unsuccessful session set-up 
and an unsuccessful session unrelated request. This parameter 
corresponds to SIP Response Timestamp. Present with Charging 
Data Request [Start] and Charging Data Request [Event]. 


Service Delivery Start Time Stamp 
Fraction 


Om 


This parameter contains the milliseconds fraction in relation to the 
Service Delivery Start Time Stamp. 


Service Delivery End Time Stamp 


Oc 


This field records the time at which the service delivery was 
terminated. It is Present only in SIP session related case. This 
parameter corresponds to SIP Request Timestamp. Present with 
Charging Data Request [Stop]. 
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Field 


Category 


Description 


Service Delivery End Time Stamp 
Fraction 


Oc 


This parameter contains the milliseconds fraction in relation to the 
Service Delivery End Time Stamp. 


Record Opening Time 


Oc 


A time stamp reflecting the time the CDF opened this record. Present 
only in SIP session related case. 


Record Closure Time 


Om 


A Time stamp reflecting the time the CDF closed the record. 


Inter Operator Identifiers 


Oc 


Holds the identification of the home network (originating and 
terminating) if exchanged via SIP signalling, as recorded in the P- 
Charging-Vector header. 


Originating 101 


Oc 


This parameter corresponds to Ong-IOI header of the P-Charging- 
Vector defined in TS 24.229 [204]. 


Terminating 101 


Oc 


This parameter corresponds to Term-IOI header of the P-Charging- 
Vector defined in I b 2.^.2.2.2 [<^04J. 


Local Record Sequence Number 


Om 


This field includes a unique record number created by this node. The 
number is allocated sequentially for each partial CDR (or whole CDR) 
including all CDR types. The number is unique within the CDF. 


Record Sequence Number 


Oc 


This field contains a running sequence number employed to link the 

partial records generated by the CDF for a particular session. 


Cause For Record Closing 


Om 


This field contains a reason for the close of the CDR. 


Incomplete CDR Indication 


Oc 


This field provides additional diagnostics when the CDF detects 
missing Charging Data Requests. 


IMS Charging Identifier 


Om 


This parameter holds the IMS charging identifier (ICID) as generated 
by the IMS node for the SIP session. 


List of Early SDP IVIedia Components 


Oc 


This is a grouped field which may occur several times in one CDR. 
Each occurrence shall describe a change in the state (inactive/active 
or vice versa) of the media components negotiated during the SIP 
session establishment previously to the reception of a SIP final 
response to the initial SIP Invite. 

This field shall not be present if no media components are set to 
active before the final SIP session answer to the initial SIP Invite is 
received. 

This field can be present in either session or event CDRs. 


SDP Session Description 


Oc 


Holds the Session portion of SDP data exchanged in the above 
mentioned scenario, if available. 


SDP Type 


Om 


This parameter indicates if the SDP media component is an SDP 
offer or SDP answer. 


SDP Offer Timestamp 


Om 


This parameter contains the time of the SIP Request which conveys 
the bUr otter. 


SDP Answer Timestamp 


Om 


This parameter contains the time of the response to the SIP Request 
which conveys the SDP answer. 


SDP IVIedia Components 


Om 


This is a grouped field comprising several sub-fields associated with 
one media component. Since several media components may exist 
for a session in parallel these sub-fields may occur several times. 


SDP Media Name 


Om 


This field holds the name of the media as available in the SDP data. 


SDP Media Description 


Om 


This field holds the attributes of the media as available in the SDP 
data. 


Access Correlation ID 


Oc 


This parameter holds the charging identifier from the access network, 
consisting of either GPRS charging ID (GCID) which is generated by 
the GGSN for a GPRS PDP context. Charging Id which is generated 
by P-GW for IP-CAN bearer or the Access Network Charging 
Identifier Value which is generated by another type of access 
network. 

It is present only if received from the access network when PCC 
architecture is implemented. 


Media Initiator Flag 


Oc 


This field indicates if the called party has requested the session 
modification and it is present only if the initiator was the called party. 


List of SDP Media Components 


Oc 


This is a grouped field which may occur several times in one CDR. 
The first occurrence describes the initial session negotiation whilst 
the other would stem from session re-negotiations, including transfer 
CS to PS or PS to CS. 

The field is present only in a SIP session related case. 
When "OneChargingSession" option applies, only SDP media 
components received by the ATCF are included, i.e those generated 
by the ATCF are not included. 


SDP Session Description 


Oc 


Holds the Session portion of the SDP data exchanged between the 
User Agents if available in the SIP transaction. 
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'^^^^^^^^^^^H Category 


Description 


SDP Type 


Om 


Tliis parameter indicates if the SDP media component is an SDP 
offer or SDP answer. 


SIP Request Timestamp 


Oc 


This parameter contains the time of the SIP Request (usually a 
(Re)lnvite). This parameter corresponds to SIP Request Timestamp 

in Charging Data Request [Interim]. 


SIP Response Timestamp 


Oc 


This parameter contains appropriately the time of 200 OK 
acknowledging an INVITE or of ACK including an SDP answer. This 
parameter corresponds to SIP Response Timestamp in Charging 
Data Request [Interim]. 


SIP Request Timestamp Fraction 


Oc 


This parameter contains the milliseconds fraction in relation to the 
SIP Request Timestamp. 


SIP Response Timestamp 
Fraction 


Oc 


This parameter contains appropriately the time of 200 OK 
acknowledging an INVITE or of ACK including an SDP answer. This 
parameter corresponds to SIP Response Timestamp in Charging 
Data Request [Interim]. 


SDP Media Components 


Om 


This is a grouped field comprising several sub-fields associated with 

one media component. Since several media components may exist 
for a session in parallel these sub-fields may occur several times. 


SDP Media Name 


Om 


This field holds the name of the media as available in the SDP data. 


SDP Media Description 


Om 


This field holds the attributes of the media as available in the SDP 
data. 


Access Correlation ID 


Oc 


This parameter holds the charging identifier from the access network, 
consisting of either GPRS charging ID (GCID) which is generated by 
the GGSN for a GPRS PDP context, Charging Id which is generated 
by P-GW for IP-CAN bearer or the Access Network Charging 
Identifier Value which is generated by another type of access 
network. 

It is present only if received from the access network when PCC 
architecture is implemented. 


Media Initiator Flag 


Oc 


This field indicates if the called party has requested the session 
modification and it is present only if the initiator was the called party. 


GGSN Address 


Oc 


This parameter holds the control plane IP address of the GGSN that 
handles one or more media component(s) of a IMS session. 


Service Reason Return Code 


Om 


This parameter provides the returned SIP status code for the service 
request for the successful and failure case. 


List of Message Bodies 


Oc 


This grouped field comprising several sub-fields describing the data 
that may be conveyed end-to-end in the body of a SIP message. 
Since several message bodies may be exchanged via SIP-signalling, 
this grouped field may occur several times. 


Content-Type 


Om 


This sub-field of Message Bodies holds the MIME type of the 
message body. Examples are: application/zip, image/gif, audio/mpeg, 
etc. 


Content-Disposition 


Oc 


This sub-field of Message Bodies holds the content disposition of the 
message body inside the SIP signalling. Content-disposition header 
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field equal to render , indicates that the body part should be 
displayed or otherwise rendered to the user". Content disposition 
values are : session, render, inline, icon, alert, attachment, etc. 


Content-Length 


Om 


This sub-field of Message Bodies holds the size of the data of a 
message body in bytes. 


Originator 


Oc 


This sub-field of the "List of Message Bodies" indicates the 
originating party of the message body. 


Access Network Information 


Oc 


This field contains the content of the first available SIP P-header "P- 

Access-Network-lnfo" if available. 


List of Access Transfer Information 


Oc 


This field is a list of grouped field describing the subsequent CS to 
PS or PS to CS session transfers. 
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Each other occurence comprises sub-fields describing the session 
transfer performed. 


Access Transfer Type 


Oc 


This field contains indication about the access transfer performed: 
CS to PS, or PS to CS.This field is present only when transfer 
occurred. 


Access Network Information 


Oc 


This field holds the content of the SIP P-header "P-Access-Network- 
Info" from the INVITE requesting the transfer. 


Service Context Id 


Om 


Holds the context information to which the CDR belongs. The 
information is obtained from the Operation Token of the Charging 
Data Request message. 
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Field 


Category 


Description 


IMS Communication Service ID 


Oc 


This field contains the IMS communication service identifier if 
received in the P-Asserted-Service header in the SIP request. 


Initial IMS Charging Identifier 


Oc 


This parameter holds the Initial IMS charging identifier (ICID) as 
generated by the IMS node for the initial SIP session created for IMS 
service continuity. 

This field is not used for the "OneChargingSession" option. 


User Location Info 


Oc 


This field indicates details of where the UE is currently located (e.g. 
SAI, TAI, RAI, CGI, ECGI or access-specific user location 
information). 


MS Time Zone 


Oc 


This field indicates the offset between universal time and local time in 
steps of 15 minutes of where the MS currently resides. 


From Address 


Om 


Contains the information from the SIP From header. 


Record Extensions 


Oc 


A set of operator/manufacturer specific extensions to the record, 
conditioned upon existence of an extension. 



NOTE: ATCF collocated with P-CSCF or IBCF applies combined offline charging with applicable fields described 
in table 6.3.2.1 

Editor's note: User Location Information and MS Time Zone to be updated after CTl stage 3 work is completed. 
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6.1.3.14 TFCDR Content 

The detailed description of the field is provided in TS 32.298 [51]. 



Table 6.1.3.14: Charging Data of TF CDR 









Record Type 


M 


Identifies the type of record. The parameter is derived from the Node functionality 

parameter. 


Retransmission 


Oc 


This parameter, when present, indicates that information from retransmitted Charging 
Data Requests has been used in this CDR 


SIP Method 


Oc 


Specifies the SIP-method for which the CDR is generated. Only available in session 
unrelated cases. 


Event 


Oc 


This field identifies the SIP event package to which the SIP request is referred. 


Expires Information 


Oc 


This field indicates the validity time of either the SIP message or its content, 
depending on the SIP method. 


Role of Node 


Oc 


This field indicates whether the Transit Functions are serving the Originating or the 
Terminating party. 


Node Address 


Om 


This item holds the address of the node providing the information for the CDR. This 
may either be the IP address or the FQDN of the IMS node generating the accounting 
data. 


Session ID 


Om 


The Session identification. For a SIP session the Session-ID contains the SIP Call ID 
as defined in the Session Initiation Protocol RFC 3261 [404]. 


Session Priority 


Oc 


The field contains the priority of the session. 


List Of Calling Party 
Address 


Om 


The address or addresses (Public User ID or Public Service ID) of the party 
requesting a service or initiating a session. In the case of no P-Asserted-ldentify is 
known, this list shall include one item with the value "unknown". 


Called Party Address 


Om 


For SIP transactions, except for registration, this field holds the address of the party 
(Public User ID or Public Service ID) to whom the SIP transaction is posted. 
For registration transactions, this field holds the Public User ID under registration. 


Requested Party 
Address 


Oc 


For SIP transactions this field holds the address of the party (Public User ID or Public 

Service ID) to whom the SIP transaction was originally posted. 

This field is only present if different from the Called Party Address parameter. 


List of Called 
Asserted Identity 


Oc 


The address or addresses of the final asserted identities. Present if the final asserted 
identities are available in the SIP 2xx response. 


Private User ID 


Oc 


Holds the used private user identity of the served party according to RFC2486 [405] if 
available. 


List of Subscription 
Id 


Oc 


Holds the public user identities of the served user 


Service Request 
Time Stamp 


Om 


This field contains the time stamp, which indicates the time at which the service was 
requested. 


Service Request 

Time Stamp Fraction 


Om 


This parameter contains the milliseconds fraction in relation to the Service Request 

Time Stamp. 


Service Delivery 
Start Time Stamp 


Om 


This field holds the time stamp reflecting either: successful session set-up, a delivery 
unrelated service, an unsuccessful session set-up and an unsuccessful session 
unrelated request. 


Service Delivery 
Start Time Stamp 
Fraction 


Om 


This parameter contains the milliseconds fraction in relation to the Service Delivery 
Start Time Stamp. 


Service Delivery End 
Time Stamp 


Oc 


This field records the time at which the service delivery was terminated. It is Present 
only in SIP session related case. 


Service Delivery End 

Time Stamp Fraction 


Oc 


This parameter contains the milliseconds fraction in relation to the Service Delivery 

End Time Stamp. 


Record Opening 
Time 


Oc 


A time stamp reflecting the time the CDF opened this record. Present only in SIP 
session related case. 


Record Closure Time 


Om 


A Time stamp reflecting the time the CDF closed the record. 


Application Servers 
Information 


Oc 


This a grouped CDR field containing the fields: "Application Server Involved" and 
"Application Provided Called Parties", to cover the case of transit network providing 
IMS application services. 


Application 
Servers Involved 


Oc 


Holds the ASs (if any) identified by the SIP URIs. 


Application 
Provided Called 
Parties 


Oc 


Holds a list of the Called Party Address(es), if the address(es) are determined by an 
AS (SIP URI, E.164...). 
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Field 


Category 


Description 


List of Inter Operator 
Identifiers 


Oc 


1 1 1 1 Xl '1 J.T" X' £ Xl 1 X 1 / ■ ' X' 1 X ■ X" \ 1 1 

Holds the identification of the home network (originating and terminating) if exchanged 
via SIP signalling, as recorded in the P-Charging-Vector header. This grouped field 
may occur several times in one CDR. 


Originating lOi 


Oc 


This parameter corresponds to Orig-IOi header of the P-Charging-Vector defined in 
TS 24.229 [204]. 


Terminating 101 


Oc 


This parameter corresponds to Term-IOI header of the P-Charging-Vector defined in 
TS 24.229 [204]. 


Transit 101 List 


Oc 


This parameter corresponds to Transit-IOI List of the P-Charging-Vector defined in TS 
24.229 [204]. 


Local Record 
Sequence Number 


Om 


^ni 'flt'll ■ 1 1 j-llxl i~ ^^1 

This field includes a unique record number created by the Transit Functions. The 
number is allocated sequentially for each partial CDR (or whole CDR) including all 

CDR types. The number is unique within the CDF. 


Record Sequence 
Number 


Oc 


This field contains a running sequence number employed to link the partial records 
generated by the CDF for a particular session. 


Cause For Record 
Closing 


Om 


This field contains a reason for the close of the CDR. 


Incomplete CDR 
Indication 


Oc 


This field provides additional diagnostics when the CDF detects missing Charging 
Data Requests. 


IMS Charging 
Identifier 


Om 


This parameter holds the IMS charging identifier (iCID) as generated by the IMS node 
for the SIP session. 


List of Early SDP 
Media Components 


Oc 


This is a grouped field which may occur several times in one CDR. 
Each occurrence shall describe a change in the state (inactive/active or vice versa) of 
the media components negotiated during the SIP session establishment previously to 
the reception of a SIP final response to the initial SIP Invite. 

^Fi ' X' 1 1 1 II X 1 X 1" X XX ■ ■ ■ r ■ 1 r* ■ 

This field shall not be present if no media components are set to active before the final 
SIP session answer to the initial SIP Invite is received. 
This field can be present in either session or event CDRs. 


SDP Session 
Description 


Oc 


Holds the Session portion of SDP data exchanged in the above mentioned scenario, if 
available. 


SDP Type 


Om 


This parameter indicates if the SDP media component is an SDP offer or SDP 
answer. 


SDP Offer 
Timestamp 


Om 


This parameter contains the time of the SiP Request which conveys the SDP offer. 


SDP Answer 
Timestamp 


Om 


This parameter contains the time of the response to the SIP Request which conveys 

the SDP answer. 


SDP Media 
Components 


Om 


^ni i.c'11 _ _ _ 1 1 f'_i_i_ _ ^ * ^ i. ^ _i 'xl I' 

This IS a grouped field comprising several sub-fields associated with one media 
component. Since several media components may exist for a session in parallel these 
sub-fields may occur several times. 


SDP Media 

Name 


Om 


This field holds the name of the media as available in the SDP data. 


SDP Media 
Description 


Om 


This field holds the attributes of the media as available in the SDP data. 


Media initiator 

Flap 


Oc 


This field indicates if the called party has requested the session modification and it is 
present only if the initiator was the called party. 


List of SDP Media 
Components 


Oc 


This is a grouped field which may occur several times in one CDR. The first 
occurrence describes the initial SIP session negotiation whilst the other would stem 
from session re-negotiations. 

The field is present only in a SIP session related case. 


SDP Session 
Description 


Oc 


Holds the Session portion of the SDP data exchanged between the User Agents if 
available in the SIP transaction. 


SDP Type 


Om 


This parameter indicates if the SDP media component is an SDP offer or SDP 
answer. 


SIP Request 
Timestamp 


Oc 


This parameter contains the time of the SIP Request (usually a (Re)lnvite). 


SIP Response 
Timestamp 


Oc 


This parameter contains appropriately the time of 200 OK acknowledging an INVITE 
or of ACK including an SDP answer. 


SIP Request 
Timestamp Fraction 


Oc 


This parameter contains the milliseconds fraction in relation to the SIP Request 

Timestamp. 


SIP Response 
Timestamp Fraction 


Oc 


This parameter contains the milliseconds fraction in relation to the SIP Response 

Timestamp. 


SDP Media 
Components 


Om 


This is a grouped field comprising several sub-fields associated with one media 
component. Since several media components may exist for a session in parallel these 
sub-fields may occur several times. 
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rieiu 


Category 


Description 


SDP Media 

Name 


Om 


This field holds the name of the media as available in the SDP data. 


SDP Media 
Description 


Om 


This field holds the attributes of the media as available in the SDP data. 


Media Initiator 
Flag 


Oc 


^Fl 'X'll'l' i "Xxl III Xl XlXl I' £' M.' I'X" 

This field indicates if the called party has requested the session modification and it is 
present only if the initiator was the called party. 


Service Reason 
Return Code 


Om 


^Fl X ■ 1 xl X 1 1 r"^ XX 1 £ xl ' X £ xl 

This parameter provides the returned SIP status code for the service request for the 
successful and failure case, 


List of Message 
Bodies 


Oc 


This grouped field comprising several sub-fields describing the data that may be 
conveyed end-to-end in the body of a SIP message. Since several message bodies 

i 1 1 ■ 1 II' xl' ix'ii ix" 

may be exchanged via SIP-signalling, this grouped field may occur several times. 


Content-Type 


Om 


This sub-field of Message Bodies holds the MIME type of the message body, 

1— 1 I'X'/"' / I'/ X 

Examples are: application/zip, image/gif, audio/mpeg, etc. 


Content- 
Disposition 


Oc 


This sub-field of Message Bodies holds the content disposition of the message body 
inside the SIP signalling. Content-disposition header field equal to "render", indicates 
that "the body part should be displayed or otherwise rendered to the user". Content 
disposition values are: session, render, inline, icon, alert, attachment, etc. 


Content-Length 


Om 


This sub-field of Message Bodies holds the size of the data of a message body in 
bytes. 


Originator 


Oc 


This sub-field of the "List of Message Bodies" indicates the originating party of the 
message body. 


Service Context Id 


Om 


Holds the context information to which the CDR belongs. The information is obtained 
from the Operation Token of the Charging Data Request message. 


IMS Communication 
Service ID 


Oc 


This field contains the IMS communication service identifier if received in the P- 
Asserted-Service header in the SIP request. 


Real Time Tariff 
Information 


lln 


This field holds the tariff/add-on charge received. 


ININI IIIIUIIIIClLIUIl 




Thic nmi moH fiolH hnlHc infrirmatirin ahmittho MMI i icoH f nr into rr^nnnor'tinn a nH 

1 lllo LjlUU|JUU IICIU IIUIUo iliiUllilClllUII ClUUUL 11 Ic; iNlNI Uoc;U lUI IIILUIOUIIIIC^L'LIUII ClIIU 

roaming on the loopback routing path. It is present only if "VPLMN routing" is applied 
in a Roaming Architecture for Voice over IIVIS with Local breakout. 


NNI Type 


Oc 


This field indicates usage of the roaming NNI for loopback routing, i.e S-CSCF 
performed the loopback decision. 


From Address 


Om 


Contains the information from the SIP From header. 


Record Extensions 


Oc 


A set of operator/manufacturer specific extensions to the record, conditioned upon 
existence of an extension. 



Editor's note: More investigation on parameters occurrence should be worked out. 
Editor's note: The rules for populating the Transit-IOI List field are PES. 
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6.2 Data description for IIVIS online cliarging 
6.2.1 Ro message contents 

The IMS nodes generate debit and reserve units information that can be transferred from the CTF to the OCF. For this 
purpose, IMS online charging utilises the Debit Units and Reserve Units procedure that is specified in the 3GPP debit 
unit operation in TS 32.299 [50]. 

The Debit and reserve units procedure employs the Debit and Reserve Units Request and Debit and Reserve Units 
Response messages. Table 6.2.1 describes the use of these messages in IMS onhne charging. 



Table 6.2.1 : Online Charging Messages Reference Table 



Command-Name 


Source 


Destination 


Debit and Reserve Units Request 


MRFC, AS, IIVIS-GWF 


ocs 


Debit and Reserve Units Response 


CCS 


IVIRFC, AS, II^S-GWF 
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6.2.1 .1 Debit and Reserve Units Request Message 

Table 6.2. 1 . 1 illustrates the basic structure of a Debit and Reserve Units Request message from the CTF in MRFC and 
AS and the IMS-GWF as used for IMS onhne charging. 



Table 6.2.1.1: Debit and reserve units Request lUlessage Contents 



Field 


Category 




Session Identifier 


M 


Described in 32.299 [50] 


Originator Host 


M 


Described in 32.299 [50] 


Originator Domain 


M 


Described in 32.299 [50] 


Destination Domain 


M 


Described in 32.299 [50] 


Operation Identifier 


M 


Described in 32.299 [50] 


Operation Tol<en 


M 


Described in 32.299 [50] 


Operation Type 


M 


Described in 32.299 [50] 


Operation Number 


M 


Described in 32.299 [50] 


Destination Host 


Oc 


Described in 32.299 [50] 


User Name 


Oc 


The field contains the Private User Identity [201] 


Origination State 


Oc 


Described in 32.299 [50] 


Origination Timestamp 


Oc 


Described in 32.299 [50] 


Subscriber Identifier 


Om 


This field contains the identification of the mobile subscriber (i.e. MSISDN or SIP- 
URI) that uses the requested service. 


Termination Cause 


Oc 


Described in 32.299 [50] 


Requested Action 


Oc 


Described in 32.299 [50] 


Multiple Operation 


Om 


Described in 32.299 [50] 


Multiple Unit Operation 


Oc 


Described in 32.299 [50] 


Subscriber Equipment 
Number 


Oc 


Described in 32.299 [50] 


Proxy Information 


Oc 


Described in 32.299 [50] 


Route Information 


Oc 


Described in 32.299 [50] 


Service Information 


Om 


This field holts additional 3GPP service specific parameter: 

- IMS Information, 

- PS Information 


Extended Information 


Oc 


This field holds the network/manufacturer specific extensions. 
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6.2.1 .2 Debit and Reserve Units Response Message 

Table 6.2.1.2 illustrates the basic structure of a Debit and Reserve Units Response message as used for IMS charging. 
This message is always used by the OCS as specified below, independent of the receiving IMS node and the operation 
type that is being repUed to. 



Table 6.2.1.2: Debit and Reserve Units Response lUlessage Contents for lUlRFC, AS and IIUIS-GWF 



Field 


Category 




Session Identifier 


M 


Described in 32.299 [50] 


Operation Result 


M 


Described in 32.299 [50] 


Originator Host 


IVI 


Described in 32.299 [50] 


Originator Domain 


M 


Described in 32.299 [50] 


Operation Identifier 


M 


Described in 32.299 [50] 


Operation Type 


M 


Described in 32.299 [50] 


Operation Number 


IVI 


Described in 32.299 [50] 


Operation Failover 


Oc 


Described in 32.299 [50] 


Multiple Unit Operation 


Oc 


Described in 32.299 [50] 


Operation Failure 

Action 


Oc 


Described in 32.299 [50]. This field defines the operation if a failure has occurred at 
the OCS for SCUR and ECUR. 


Operation Event Failure 
Action 


Oc 


Described in 32.299 [50]. This field defines the operation if a failure has occurred at 
the OCS for lEC. 


Redirection Host 


Oc 


Described in 32.299 [50] 


Redirection Host Usage 


Oc 


Described in 32.299 [50] 


Redirection Cache Time 


Oc 


Described in 32.299 [50] 


Proxy Information 


Oc 


Described in 32.299 [50] 


Route Information 


Oc 


Described in 32.299 [50] 


Failed parameter 


Oc 


Described In 32.299 [50] 


Service Information 


Oc 


This field holts additional 3GPP service specific parameter: 

- IIVIS Information, 

- PS Information 


Extended Information 


Oc 


This field holds the network/manufacturer specific extensions. 
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6.3 IMS Charging Specific Parameters 
6.3.1 Definition of IIVIS cliarging information 

The IMS Information parameter used for IMS charging is provided in the Service Information parameter. 

6.3.1 .1 IMS charging information assignment for Service Information 

The components in the Service Information that are use for IMS charging can be found in Table 6.3.1.1. 



Table 6.3.1.1 : Service Information used for IMS Charging 



Field 


Category 


Description 


Provided 
by IMS NE 


Service Information 


Om 


This is a structured field and holds the 3GPP specific 
parameter as defined in TS 32.299 [50]. For IMS 
Charging the IMS Information is used. 


All 


Subscription-Id 


Om 


Described in TS 32.299 [50] and contains the Private 
User Identity and / or Public User Identity/Identities 


All 


IIVIS Information 


Om 


This is a structured field and holds the IMS specific 
parameters. The details are defined in clause 6.3.1 .2. 


All 


PS Information 


Oc 


This is a structured field and holds PS specific 
parameters. The complete structure is defined in TS 
32.251 [11]. 


Not in 
l-CSCF, IBCF 


GGSN Address 


Oc 


This field holds the IP-address of the GGSN that 
generated the GPRS Charging ID, as described in [1]. 


Not in 
l-CSCF, MGCF, 
BGCF, 
IBCF 


User Location 
Info 


Oc 


This field indicates details of where the UE is currently 
located (e.g. SAI, TAI, RAI, CGI, ECGI or access-specific 
user location information). 


Not in 
MGCF, 
BGCF 


MS Time Zone 


Oc 


This field indicates the offset between universal time and 
local time in steps of 1 5 minutes of where the MS 
currently resides. 


Not in 
MGCF, 
BGCF 



Editor's note: User Location Information and MS Time Zone to be updated after CTl stage 3 work is completed. 



6.3.1 .2 Definition of the IMS Information 

IMS specific charging information is provided within the IMS Information. The fields of the IMS Information which 
are differently covered in several IMS network nodes are indicated by the node specific type. 

The detailed structure of the IMS Information can be found in table 6.3.1.2. 



Table 6.3.1.2: Structure of the IMS Information 



Field 


Category 


Description 


Provided 
by IIVIS NE 


Event Type 


Oc 


This field holds the SIP Method, the content of the SIP "Event" 
header and the content of the SIP "expires" header when 
present in the SIP request. 


All 


Node Functionality 


M 


This field contains the function of the node. 


All 


Role of Node 


Om 


This field specifies whether the IMS node is serving the 
Originating or the Terminating party. 


Not in MRFC 


User Session ID 


Om 


This field holds the session identifier. For a SIP session the 
Sess/on-/D contains the SIP Call ID. When the AS acts as 
B2BUA, the incoming session is identified. 


All 


Outgoing Session ID 


Oc 


When the AS acts as B2BUA, the outgoing side session is 
identified by the Outgoing Session ID which contains the SIP 
Call ID. 


AS only 
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Category 




Provided 
by iiUIS NE 


Session Priority 


Oc 


This field contains the priority of the session. 


All 


Calling Party Address 


Om 


This field holds the address (SIP URI or TEL URI)URI of the 
party (Public User Identity or Public Service Identity) initiating a 
session or requesting a service. 


All 


Called Party Address 


Om 


For SIP transactions, except for registration, this field holds the 
address of the party (Public User ID or Public Service ID) to 
whom the SIP transaction is posted. 

For registration transactions, this field holds the Public User ID 
under registration. 


All 


Number Portability 
routing information 


Oc 


This field includes information on number portability after 
DNS/ENUM request from IMS node in the calling user's home 
network. 


S-CSCF, l-CSCF, 

AS, MGCF, 
BGCF, E-CSCF 


Carrier Select routing 
information 


Oc 


This field includes information on carrier select after 
DNS/ENUM request from IMS node in the calling user's home 
network. 


S-CSCF, i CSCF, 
AS, MGCF, 
BGCF, E-CSCF 


Alternate Ctiarged 
Party Address 


Oc 


The address of an alternate party that is identified by the AS at 
session initiation, and is charged in place of the calling party. 


AS only 


Requested Party 
Address 


Oc 


For SIP transactions this field holds the address of the party 
(Public User ID or Public Service ID) to whom the SIP 
transaction was originally posted. 
This field is only present if different from the Called Party 
Address parameter. 


S-CSCF, P-CSCF, 
E-CSCF, and 
AS/MRFC, IF, 
TRF, ATCF 


Called Asserted 
Identity 


Oc 


The address of the final asserted identity. Present if the final 

i I'l i'j. 'Ill xi 1 n 

asserted identity is available in the SIP 2xx response. 


S-CSCF, E-CSCF 
and AS/MRFC, 
TP, TRF, ATCF 


Associated URI 


Oc 


This field holds a non-barred public user identity (SIP URI or 

—I— 1— 1 II f~\ t\ 'xlixl IM '1 I ■ I 1 

TEL URI) associated to the public user identity under 
registration and is present for registration transactions. 


S-CSCF, P-CSCF, 
l-CSCF, IBCF, E- 
CSCF 


Time Stamps 


Oc 


This field holds the time of the SIP REQUEST and the time of 
the response to the SIP REOUEST. 


All 


Application Server 
Information 


Oc 


This field holds the SIP URI(s) of the AS(s) addressed during 
the session and the called party number (SIP URI, E.164), if an 

application server determines it. 


S-CSCF, E-CSCF, 
and MRFC, TF, 
TRF 


Inter Operator Identifier 


Oc 


This field holds the identification of the network neighbours 
(originating and terminating) as exchanged via SIP signalling if 

■ 1 LI ^ni ' t I 1 X' 

available. This field may occur several times. 


All 


IMS Charging Identifier 


Om 


This field holds the IMS Charging Identifier (ICID) as generated 
by a IMS node for a SIP session. 


All 


Related IMS Cliarging 
Identifier 


Oc 


This field holds the Related IMS charging identifier when the 
session is the target access leg in an SRVCC CS to PS 
handover. The Related IMS charging identifier contains the IMS 
charging identifier as generated by the Enhanced MSC server. 


P-CSCF 


Related IMS Charging 
Identifier Generation 

Node 


Oc 


This field holds the identifier of the Enhanced MSC server that 
generated the Related IMS charging identifier. 


P-CSCF 


Transit 101 List 


Oc 


This field holds the identification of the involved transit networks 
as exchanged via SIP signalling if available. This field may 

occur several times. 


S-CSCF, P-CSCF, 
MRFC, MGCF, 
BGCF, SIP AS. 

IBCF, TF and TRF 


Early Media 
Description 


Oc 


This field holds session and media parameters related to media 
components set to active during the SIP session establishment 
and before a final successful or unsuccessful SIP answer to the 
initial SIP INVITE request is received. Once a media 
component is set to active, subsequent status changes shall be 
registered. Since several SDP negotiations may occur during 
the SIP session establishment, this field may occur several 
times. 


Not in l-CSCF 


SDP Session 
Description 


Oc 


This field holds the content of an "attribute-line" (i=, c=, b=, k=, 
a=, etc.) related to a session. 


Not in 
l-CSCF 


SDP Media 
Component 


Oc 


This is a grouped field comprising several sub-fields associated 
with one media component. Since several media components 
may exist for a session in parallel these sub-fields may occur 
several times. 


Not in 
l-CSCF 
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Field 


Category 


Description 


Provided 

Dy IMo Nt 


berved rarty Ir 
Address 


Oc 


This field holds the IP address of either the calling or called 
party, depending on whether the P-CSCF is in touch with the 
calling or the called party. 


H-CbCr 


Server Capabilities 


Oc 


This field contains the server capabilities as described in 3GPP 
TS 29.229 [205]. 


l-ObOr 


Trunl< Group ID 


Oc 


This field identifies the incoming and outgoing PSTN legs. 


M(jOr 


Bearer Service 


Oc 


This field holds the used bearer service for the PSTN leg. 


MGCF 


Service Id 


Oc 


This field identifies the service the MRFC is hosting. For 
conferences the conference ID is used as the value of this 
parameter. 


MRFC 


Service Specific Info 


Oc 


This field contains service specific data if and as provided by an 
Application Server. 


AS 


Message Bodies 


Oc 


This field holds information about the Message body, Content- 
Type, Content-Length, Content-Disposition and Originator if 
available. 


P-CSCF, S-CSCF, 
E-CSCF, MGCF, 
IBCF, ATCF and 
AS 


Access Network 
Information 


Oc 


This field contains the content of the P-header P-Access- 
Network-lnfo. 


Not in TF norTRF 


Access Transfer 
Information 


Oc 


This field contains information related to the CS to PS or PS to 
CS session transfer. 


AS and ATCF 


IMS Communication 
Service ID 


Oc 


^ni '£'11 i ' J.I IK Mf^ ' ±' ■ ' 1 A.'£' 'L 

This field contains the IMS communication service identifier if 
received in the P-Asserted-Service header in the SIP request. 


S-CSCF, P-CSCF, 
E-CSCF, IBCF, 
ATCF, TRF and 
Ab 


IMS Application 
Reference ID 


Oc 


This field contains the IMS application reference identifier if 
received in the SIP request. 


P-CSCF 


Cause Code 


Oc 


This field contains the cause value. 


All 


Real Time Tariff 
Information 


Oc 


This field holds the tariff/add-on charge received. 


S-CSCF, IBCF, 
MGCF, AS, TF, 
TRF 


Online Charging Flag 


Oc 


This field indicates the Online Charging Request was sent 
based on the provided ECF address from the SIP P-header "P- 
Charging-Function-Addresses". 

NOTE: No proof that online charging action has been taken 


S-CSCF and 
AS/MRFC 


Account Expiration 


Oc 


This field indicates the subscriber account expiration date and 
Time or uay. 


OCS 


iniiiai iMo onarging 
Identifier 




This fiGid holds thG InitisI IMS chsrging idGntifiGr (ICID) as 
QGHGratGd by thG IMS node fortho initial SIP SGSsion crGatod 

lUl llvIO oc;l VILfC LfUl ILIl lUliy. 


Ao ano A 1 or 


NNI Information 


oc 


This fiGid holds information about tho NNI usod for 
Intprmnnpptinn and rnpminn 


S-CSCF, BGCF, 
IBCF TF TRF 

1 l_f V_/ 1 , ' ' ) 1 1 1 1 


From Address 


OM 


Contains the information from the SIP From header. 


All 


IMS Emergency 
Indication 


Oc 


This field indicates the registration is an emergency registration 
or the IMS session is an IMS emergency session 


P-CSCF, S-CSCF, 
l-CSCF 


IMS Visited Network 
Information 


Oc 


Contains the information from the SIP P-Visited-Network-ID 
header. 


P-CSCF, S-CSCF, 
and AS 



Editor's note: The completeness of indications for the E-CSCF and the TRF is ffs. 
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6.3.2 Detailed Message Format for offline charging 

The following chapter specifies per Operation Type the charging data that are sent by each of the IMS network elements 
for: 

• IMS session and IMS event (S/I/S/E) 

• S-CSCF, E-CSCF, P-CSCF, MGFC, AS, IBCF, TRF, ATCF, TF 

• IMS session only (S/I/S) 

• MRFC 

• IMS event only (E) 

• I-CSCF, BGCF 



The Operation Types are listed in the following order: S (start)/I (interim)/S (stop)/E (event). Therefore, when all 
Operation Types are possible it is marked as SISE. If only some Operation Types are allowed for a node, only the 
appropriate letters are used (i.e. SIS or E) as indicated in the table heading. The omission of an Operation Type for a 
particular field is marked with "-" (i.e. SI-E). Also, when an entire field is not allowed in a node the entire cell is 
marked as 
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Table 6.3.2.1 illustrates the basic stracture of the supported fields in the Charging Data Request message for IMS 
offline charging. 



Table 6.3.2.1 : Supported fields in Charging Data Request Message 



Field Node Type 


S- 
CSCF 


E- 
CSCF 


P- 
CSCF 


1- 

CSCF 


MRFC 


MGCF 


BGCF 


AS 


IBCF 


TF 


TRF 


ATCF 


Supported 
Operation Types 


S/l/S/E 


S/l/S/E 


S/l/S/E 


E 


S/l/S 


S/l/S/E 


E 


S/l/S/E 


S/l/S/E 


S/l/S/E 


S/l/S/E 


S/l/S/E 


Session Identifier 


SISE 


SISE 


SISE 


E 


SIS 


SISE 


E 


SISE 


SISE 


SISE 


SISE 


SISE 


Originator Node 


SISE 


SISE 


SISE 


E 


SIS 


SISE 


E 


SISE 


SISE 


SISE 


SISE 


SISE 


Originator Domain 


SISE 


SISE 


SISE 


E 


SIS 


SISE 


E 


SISE 


SISE 


SISE 


SISE 


SISE 


Destination Domain 


SISE 


SISE 


SISE 


E 


SIS 


SISE 


E 


SISE 


SISE 


SISE 


SISE 


SISE 


Operation Type 


SISE 


SISE 


SISE 


E 


SIS 


SISE 


E 


SISE 


SISE 


SISE 


SISE 


SISE 


Operation Number 


SISE 


SISE 


SISE 


E 


SIS 


SISE 


E 


SISE 


SISE 


SISE 


SISE 


SISE 


Operation Identifier 


SISE 


SISE 


SISE 


E 


SIS 


SISE 


E 


SISE 


SISE 


SISE 


SISE 


SISE 


User Name 


SISE 


SISE 


SISE 


E 


SIS 


SISE 


E 


SISE 


SISE 


SISE 


SISE 


SISE 


Operation Interval 


SISE 


SISE 


SISE 


E 


SIS 


SISE 


E 


SISE 


SISE 


SISE 


SISE 


SISE 


Origination State 


SISE 


SISE 


SISE 


E 


SIS 


SISE 


E 


SISE 


SISE 


SISE 


SISE 


SISE 


Origination 
Timestamp 


SISE 


SISE 


SISE 


E 


SIS 


SISE 


E 


SISE 


SISE 


SISE 


SISE 


SISE 


Proxy Information 


SISE 


SISE 


SISE 


E 


SIS 


SISE 


E 


SISE 


SISE 


SISE 


SISE 


SISE 


Route Information 


SISE 


SISE 


SISE 


E 


SIS 


SISE 


E 


SISE 


SISE 


SISE 


SISE 


SISE 


Operation Tol<en 


SISE 


SISE 


SISE 


E 


SIS 


SISE 


E 


SISE 


SISE 


SISE 


SISE 


SISE 


Subscriber Identifier 


SISE 


SISE 


SISE 




SIS 






SISE 


SISE 


SISE 


SISE 


SISE 


Service Information with PS and IMS Information 




Event Type 


SISE 


SISE 


SISE 


E 


SIS 


SISE 


E 


SISE 


SISE 


SISE 


SISE 


SISE 


Role of Node 


SISE 


SISE 


SISE 


E 




SISE 


E 


SISE 


SISE 


SISE 


SISE 


SISE 


iMuuc runcLiuiiaiiLy 


SISE 


SISE 


SISE 




SIS 


SISE 


E 


SISE 


SISE 


oloc 


SISE 


SISE 


User Session Id 


SISE 


SISE 


SISE 


E 


SIS 


SISE 


E 


SISE 


SISE 


SISE 


SISE 


SISE 


Outgoing Session ID 
















SISE 










Session Priority 


S--E 


S--E 


S--E 


E 


S-- 


S--E 


E 


S--E 


S--E 


S--E 


S--E 


S--E 


Calling Party 
Address 


SISE 


SISE 


SISE 


E 


SIS 


SISE 


E 


SISE 


SISE 


SISE 


SISE 


SISE 


Called Party 

Address 


SISE 


SISE 


SISE 


E 


SIS 


SISE 


E 


SISE 


SISE 


SISE 


SISE 


SISE 


Number Portability 
routing information 


S--E 


S--E 




E 




S--E 


E 


S--E 




S--E 


S--E 




Carrier Select 
routing information 


S--E 


S--E 




E 




S--E 


E 


S--E 




S--E 


S--E 




Alternate Ctiarged 
Party Address 
















S- 










Requested Party 
Address 


S--E 


S--E 






S-- 






S--E 




S--E 


S--E 


S--E 


Called Asserted 
Identity 


S--E 


S--E 


S--E 




S-- 






S--E 




S--E 


S--E 


S--E 


Associated URI (see 
note 5) 


— E 


— E 


— E 


E 










— E 








Time stamps (see 
note 3) 


SISE 


SISE 


SISE 


E 


SIS 


SISE 


E 


SISE 


SISE 


SISE 


SISE 


SISE 


Application server 
Information (see 
note 1 ) 


SISE 


SISE 






SIS 










SISE 


SISE 




Inter Operator 
Identifiers (see note 

1) 


SISE 


SISE 


SISE 


E 


SIS 


SISE 


E 


SISE 


SISE 


SISE 


SISE 


SISE 


Transit 101 List (see 

note 1 ) 


SISE 




SISE 




SIS 


SISE 


E 


SISE 


SISE 


SISE 


SISE 




IMS Charging 
Identifier 


SISE 


SISE 


SISE 


E 


SIS 


SISE 


E 


SISE 


SISE 


SISE 


SISE 


SISE 


Related IMS 
Charging Identifier 






SISE 




















Related IMS 
Charging Identifier 
Generation Node 






SISE 




















Early Media 
Description (see 
note 4) 


S--E 


S--E 


S--E 




S-- 


S--E 


E 


S--E 


S--E 


S--E 


S--E 


S--E 


SDP Session 
Description 


SI-- 


SI-- 


SI-- 




SI-- 


SI-- 




SI-- 


SI-- 


SI-- 


SI-- 


SI-- 
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SDP Media 
Component (see 
note 4) 


SI-- 


SI-- 


SI-- 




SI-- 


SI-- 




SI-- 


SI-- 


SI-- 


SI-- 


SI-- 


GGSN Address 


SI-- 


SI-- 


SI-- 




SI-- 


SI-- 




SI-- 








SI-- 


User Location Info 


SISE 


SISE 


SISE 


E 


SIS 




E 


SISE 


SISE 




SISE 


SISE 


IVIS Time Zone 


SISE 


SISE 


SISE 


E 


SIS 


- 


E 


SISE 


SISE 


- 


SISE 


SISE 


Served Party (see 
note 1 ) 






SISE 




















Server Capabilities 
(see note 1 ) 


_ 


_ 


_ 


c 


_ 


_ 


_ 


_ 


_ 


_ 


- 


- 


Trunk Group ID (see 
note 1 ) 


- 


- 


- 




- 


SISE 


- 


- 


- 


- 


- 


- 


Bearer Service (see 
note 1 ) 


- 


- 


- 




- 


SISE 


- 


- 


- 


- 


- 


- 


Service Id (see note 
1) 








- 


SIS 
















Service Specific Info 
(see note 1 ) 








- 








SISE 










Message Bodies 
(see note 2) 


SISE 


SISE 


SISE 






SISE 




SISE 


SISE 


SISE 


SISE 


SISE 


Cause Code 


--SE 


--SE 


--SE 


E 


--S 


--SE 


E 


--SE 


--SE 


--SE 


--SE 


--SE 


Access Network 
Information 


SISE 


SISE 


SISE 


E 


SIS 


SISE 


E 


SISE 


SISE 






SISE 


IMS Communication 
Service ID 


S--E 


S--E 


S--E 




- 


- 


- 


S--E 


S--E 


S--E 


S--E 


S--E 


IMS Application 
Reference ID 


" 




S--E 


- 








~ 


~ 








Real Time Tariff 

Information 


SISE 


- 


- 




- 


SISE 


- 


SISE 


SISE 


SISE 


SISE 


- 


Initial IMS Ctiarging 
Identifier 


- 


- 


- 




- 


- 


- 


SISE 


- 


- 


- 


SISE 


NNI Information 


S--E 




S--E 


- 






- 


E 


S--E 


S--E 


S--E 




From Address 


SISE 


SISE 


SISE 


E 


SIS 


SISE 


E 


SISE 


SISE 


SISE 




SISE 


Access Transfer 
Information 
















-ISE 








-ISE 


IMS Emergency 
Indication 


SISE 




SISE 


E 


















IMS Visited Network 
Identifier 


SISE 




SISE 










SISE 










NOTE 1 : Only present if available in the CTF of the IMS node. 

NOTE 2: Present only if Messages Bodies is included in the SIP message that triggered the Charging Data Request. 

NOTE 3: Only present if ACR is triggered on a SIP message (e.g. SIP INVITE, SIP UPDATE). 

NOTE 4: To be determined for presence in IBCF. 

NOTE 5: Only present if ACR is triggered on SIP REGISTER 200 OK. 
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Table 6.3.2.2 illustrates the basic structure of the supported fields in the Charging Data Response message for IMS 
offline charging. 



Table 6.3.2.2 : Supported fields in Charging Data Response Message 



Field 


Node Type 


S- 
CSCF 


E- 
CSCF 


P- 
CSCF 


i- 

CSCF 


MRFC 


MGCF 


BGCF 


AS 


IBCF 


TRF 


ATCF 


Supported 
Operation Types 


S/l/S/E 


S/i/S/E 


S/l/S/E 


E 


S/l/S 


S/i/S/E 


E 


S/l/S/E 


S/l/S/E 


S/i/S/E 


S/i/S/E 


Session Identifier 


SISE 


SISE 


SISE 


E 


SIS 


SISE 


E 


SISE 


SISE 


Q IC IZ 


SISE 


Originator Node 










Olo 




n. 






OlOC 


blob 


Originator Domain 


SISE 


SISE 


SISE 


E 


SIS 


SISE 


E 


SISE 


SISE 


SISE 


SISE 


Destination Domain 


SISE 


SISE 


SISE 


E 


SIS 


SISE 


E 


SISE 


SISE 


SISE 


SISE 


Operation Type 


SISE 


SISE 


SISE 


E 


SIS 


SISE 


E 


SISE 


SISE 


SISE 


SISE 


Operation Number 


SISE 


SISE 


SISE 


E 


SIS 


SISE 


E 


SISE 


SISE 


SISE 


SISE 


Operation Identifier 


SISE 


SISE 


SISE 


E 


SIS 


SISE 


E 


SISE 


SISE 


SISE 


SISE 


User Name 


SISE 


SISE 


SISE 


E 


SIS 


SISE 


E 


SISE 


SISE 


SISE 


SISE 


Operation Interval 


SISE 


SISE 


SISE 


E 


SIS 


SISE 


E 


SISE 


SISE 


SISE 


SISE 


Origination State 


SISE 


SISE 


SISE 


E 


SIS 


SISE 


E 


SISE 


SISE 


SISE 


SISE 


Origination TImestamp 


SISE 


SISE 


SISE 


E 


SIS 


SISE 


E 


SISE 


SISE 


SISE 


SISE 


Proxy Information 


SISE 


SISE 


SISE 


E 


SIS 


SISE 


E 


SISE 


SISE 


SISE 


SISE 


Route Information 


SISE 


SISE 


SISE 


E 


SIS 


SISE 


E 


SISE 


SISE 


SISE 


SISE 



6.3.3 Detailed Message Format for online charging 

The following table specifies per Operation type the charging data that are sent by each of the IMS network elements 
for: 

• IMS session and IMS event (I/U/T/E) 

• IMS-GWF, AS 

• IMS session only (I/U/T) 

• MRFC 



The Operation types are hsted in the following order: I (initial)/U (update)/T (terminate)/E (event). Therefore, when all 
Operation types are possible it is marked as lUTE. If only some Operation types are allowed for a node, only the 
appropriate letters are used (i.e. lUT or E) as indicated in the table heading. The omission of an Operation type for a 
particular field is marked with "-" (i.e. lU-E). Also, when an entire filed is not allowed in a node the entire cell is 
marked as 

Note that not for all structured fields the individual field members are Usted in the table. Detailed descriptions of the 
fields are provided in TS 32.299 [50]. 
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Table 6.3.3.1 illustrates the basic structure of the supported fields in the Debit and Reserve Units Request for IMS 
online charging. 



Table 6.3.3.1 : Supported fields in Debit and Reserve Units Request lUlessage 



Field 


Node Type 


IMS-GWF 


MRFC 


AS 


Supported 


l/U/T/E 


l/U/T 


l/U/T/E 


Session Identifier 


lUTE 


lUT 


lUTE 


Originator Host 


lUTE 


lUT 


lUTE 


Originator Domain 


lUTE 


lUT 


lUTE 


Destination Domain 


lUTE 


lUT 


lUTE 


Operation Identifier 


lUTE 


lUT 


lUTE 


Operation Token 


lUTE 


lUT 


lUTE 


Operation Type 


lUTE 


lUT 


lUTE 


Operation Number 


lUTE 


lUT 


lUTE 


Destination Host 


lUTE 


lUT 


lUTE 


User Name 


lUTE 


lUT 


lUTE 


Origination State 


lUTE 


lUT 


lUTE 


Origination Timestamp 


lUTE 


lUT 


lUTE 


Subscriber Identifier 


lUTE 


lUT 


lUTE 


Termination Cause 


— T- 


— T 


— T- 


Requested Action 


lUTE 


lUT 


lUTE 


IVlultiple Operation 


lUTE 


lUT 


lUTE 


Multiple Unit Operation 


lUTE 


lUT 


lUTE 


Service Units Requested 


lU-E 


lU- 


lU-E 


Action Requested 


— E 




— E 


Service Units Used 


-UT- 


-UT 


-UT- 


Subscriber Equipment Number 


lUTE 


lUT 


lUTE 


Proxy Information 


lUTE 


lUT 


lUTE 


Route Information 


lUTE 


lUT 


lUTE 


Extended Information 


lUTE 


lUT 


lUTE 




Event Type 


lUTE 


lUT 


lUTE 


Role Of Node 


lUTE 




lUTE 


Node Functionality 


lUTE 


lUT 


lUTE 


User Session Id 


lUTE 


lUT 


lUTE 


Outgoing Session ID 






lUTE 


Session Priority 


I--E 


I-- 


I--E 


Calling Party Address 


lUTE 


lUT 


lUTE 


Called Party Address 


lUTE 


lUT 


lUTE 


Number Portability routing information 


I--E 




I--E 


Carrier Select routing information 


I--E 




I--E 


Requested Party Address 


I--E 


I-- 


I--E 


Called Asserted Identity 


-U-E 


-U- 


-U-E 


Associated URI 


— E 






Application Server Information 


lUTE 


lUT 




Inter Operator Identifier 


lUTE 


lUT 


lUTE 


Transit 101 List 


lUTE 


lUT 


lUTE 


IMS Charging Identifier 


lUTE 


lUT 


lUTE 


SDP Session Description 


IU-- 


lU- 


IU-- 


SDP Media Component 


IU-- 


lU- 


IU-- 


GGSN Address 


IU-- 


lU- 


IU-- 


User Location Info 


lUTE 


lUT 


lUTE 


MS Time Zone 


lUTE 


lUT 


lUTE 


Served Party 








Server Capabilities 








Trunk Group ID 








Bearer Service 








Service Id 




lUT 




Service Specific Info 








Messages Bodies 


lUTE 




lUTE 


Cause Code 


--TE 


--T 


--TE 


Access Network Information 


lUTE 


lUT 


lUTE 


IMS Communication Service ID 


l-E 




1— E 
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Tariff Information 


-UT- 




-UT- 


Initial IMS Charging Identifier 






lUTE 


From Address 


lUTE 


lUT 


lUTE 


IMS Emergency Indication 








IMS Visited Network Identification 


lUTE 




lUTE 



Table 6.3.3.2 illustrates the basic stracture of the supported fields in the Debit and Reserve Units Response for IMS 
onUne charging. 



Table 6.3.3.2: Supported fields in Debit and Reserve Units Response Message 



Field 


^^^^fiiode Type 


ilUIS-GWF 


MRFC 


AS 


Supported 


l/U/T/E 


1 /I 1 /T 

l/U/T 


l/U/T/E 


Session Identifier 


lUTE 


lUT 


lUTE 


Operation Result 


lUTE 


lUT 


lUTE 


Originator Host 


lUTE 


lUT 


lUTE 


Originator Domain 


lUTE 


lUT 


lUTE 


Operation identifier 


lUTE 


lUT 


lUTE 


Operation Type 


lUTE 


lUT 


lUTE 


Operation Number 


lUTE 


lUT 


lUTE 


Operation Failover 


lUTE 


lUT 


lUTE 


Multiple Unit Operation 


lUTE 


lUT 


lUTE 


Operation Failure Action 








Redirection Host 








Redirection Host Usage 








Redirection Cache Time 








Proxy Information 








Route Information 








Failed parameter 








Extended Information 


lUTE 


lUT 


lUTE 


Service Information with IMS information 


Account Expiration 






lUTE 



6.3.4 Formal IMS charging parameter description 

6.3.4.1 IMS charging information for CDRs 

The detailed definitions, abstract syntax and encoding of the IMS CDR parameters are specified in TS 32.298 [51]. 

6.3.4.2 IMS charging information for charging events 

The detailed charging event parameter definitions are specified in 3GPP TS 32.299 [50]. 
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Annex A (informative): 
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b) 
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c) 
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e) 
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Annex B (informative): 

Message Flows for Service Termination by OCS 

This annex describes several scenarios related to IMS service termination in IMS-GWF. 

SIP messages and Diameter transactions associated with these charging scenarios are shown primarily to illustrate the 
service termination procedures. They are not intended to be exhaustive and depend on the Diameter Credit Control 
Requests triggers configured by the operator. The triggers for sending Debit and Reserve Unit Requests from the IMS- 
GWF to the OCS are defined according to table 5.3.1. 



B.1 Scenario 1 - Session Related (SCUR): Service 
Termination on reception of an initial SIP INVITE 
Request 



UE 



P-CSCF 



S-CSCF 



1. SIP Request (INVITE) 



4. 4xx,5xx,6xx (Error-Info) 



4. ACK 



IMS-GWF 



OCS 



1. SIP Request (INVITE) 



4. 4xx,5xx,6xx (Error-Info) 



4. ACK 



1. SIP Request ( INVITE) 



Service 
Control 



4. 4xx,5xx,6xx (Error-Info) 



4. ACK 



2. Debit and Reserve Units 
Request (INITIAL) 



3. Debit and Reserve Units 
Response (Service 
Termination) 



Figure B.1.1 : Service Termination triggered by an initial SIP Request 
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B.2 Scenario 2 - Session Related (SCUR): Service 
Termination triggered after an early SIP Dialog is 
established 



UE 



P-CSCF 



S-CSCF 



IMS- 
GWF 



OCS 



SIP early dialog established (Initial Request: SIP INVITE) 



1. 200OK 



1. 200 OK 



Service 
Control 



4. SIP BYE (Reason) 



2. Debit and Reserve Units 

Request (UPDATE) 
• 

3. Debit and Reserve Units 
i^esponse (Service Termination) 



4. SIP BYE (Reason) 



4. 200 OK to the SIP BYE 



5. 4xx,5xx,6xx (Error-Info) to 5. 4xx,5xx,6xx (Error-Info) to 
the INVITE request ^ the INVITE request 



4. 200 OK to the SIP BYE 



5. 4xx,5xx,6xx (Error-Info) to 
the INVITE request 



5. SIP ACK 



5. SIP ACK 



5. SIP ACK 



The SIP Session Is not established 



Figure B.2.1 : Service Termination triggered by the 200OK response to the initial INVITE 
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UE 



P-CSCF 



S-CSCF 



IMS-GWF 



OCS 



Early SIP dialog already established (SIP INVITE Initial method) 



1. SIP UPDATE 



1. SIP UPDATE 



5. 4xx, 5xx, 6xx (Error-Info) to 
^ reject SIP UPDATE method 



5. 4xx, 5xx, 6xx (Error-Info) to 
reject SIP UPDATE method 



. 4xx, 5xx, 6xx (Error-Info) to 
close Early Dialog 



. 4xx, 5xx, 6xx (Error-Info) 
to close Early Dialog 



6. ACK 



6. ACK 



1. SIP UPDATE 



Service 
Control 



4. SIP CANCEL to the INVITE 
^ transaction (Reason) 



5. 4xx, 5xx, 6xx (Error-Info) to 
reject SIP UPDATE method 



6. 4xx, 5xx, 6xx (Error-Info) 
^ to close Early Dialog 



6. ACK 



4. 200 OK to CANCEL In 
step 4 



2. Debit and Reserve Units 
Request (UPDATE) 



3. Debit and Reserve Units 
_^esponse (Service Termination) 



4. SIP CANCEL to the INVITE 
transaction (Reason) 



4. 200 OK to CANCEL In 
step 4 



The SIP Session Is not established 



Figure B.2.2 : Service Termination triggered by an UPDATE request within an early SIP dialog 
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P-CSCF 
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Early SIP Dialog Is already established (Initiated with a SIP INVITE) 



1. SIP UPDATE 



6. 4xx, 5xx, 6xx (Error-Info) to 
_ reject SIP UPDATE method 



7.4xx,5xx, 6xx (Error-Info) to 
^ release the 'early' dialog 



7. ACK 



1. SIP UPDATE 



3. 4xx, 5xx, 6xx (Error-Info) to 
reject SIP UPDATE method 



7.4xx,5xx, 6xx (Error-Info) to 
release the 'early' dialog 



7. ACK 



1. SIP UPDATE 



1. SIP UPDATE 



1. SIP UPDATE 



2. 200OK 



2. 200OK 



Service 
Control 



5. SIP CANCEL (Reason) to 
release the SIP early dialog 



6. 4xx, 5xx, 6xx (Error-Info) to 
^ reject SIP UPDATE method 



7.4xx,5xx, 6xx (Error-Info) to 
release the 'early' dialog 



7. ACK 



5. 200OKto SIP CANCEL 



3. Debit and Reserve Units 
Request (UPDATE) 



4. Debit and Reserve Units 
_gesponse (Service Termination) 



5. SIP CANCEL (Reason) to 
release the SIP early dialog 



5. 200OK to SIP CANCEL 



The SIP Session Is not established 



Figure B.2.3 : Service Termination triggered by the 200OK to an UPDATE request within an early SIP 

dialog 
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B.3 Scenario 3 - Session Related (SCUR): Service 

Termination triggered after a confirmed SIP Dialog is 
established 
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IMS-GWF 




OCS 



Confirmed SIP dialog already established 



1. SIP re-INVITE 



5. 4xx, 5xx, 6xx (Error-Info) 
to reject the SIP re-INVITE 



5. ACK 



. SIP BYE to release the 
Dialog (Reason) 



6. 200 OK 



1. SIP re-INVITE 



5. 4xx, 5xx, 6xx (Error-Info) 
, to reject the SIP re-INVITE 



5. ACK 



6. SIP BYE to release the 
Dialog (Reason) 



6. 200 OK 



1. SIP re-INVITE 



Service 
Control 



4. SIP BYE to release the Dialog 
^ (Reason) 



2. Debit and Reserve Units 

Request (UPDATE) 
*« 

3. Debit and Reserve Units 
Response (Service Termination) 



4. SIP BYE to release the Dialog 
(Reason) 



5. 4xx, 5xx, 6xx (Error-Info) 
, to reject the SIP re-INVITE 



5. ACK 



6. SIP BYE to release the 
Dialog (Reason) 



6. 200 OK 



4. 200 OK to SIP BYE 



4. 200 OK to SIP BYE 



The SIP Session is released 



Figure B.3.1 : Service Termination triggered by a re-INVITE request within a confirmed SIP dialog 
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UE 



P-CSCF 



S-CSCF 



IMS-GWF 



DCS 



The SIP Session is already established 



1 . SIP re-INVITE 



1. SIP re-INVITE 



6.4xx, 5xx, 6xx (Error-Info) 6.4xx, 5xx, 6xx (Error-Info) to 
to reject the re-INVITE reject the re-INVITE 



6. ACK 



6. ACK 



7. SIP BYE (Reason) 



7. SIP BYE (Reason) 



7. 200OK 



7. 200OK 



1. SIP re-INVITE 



1. SIP re-INVITE 



1. SIP re-INVITE 



2. 200OK 



2. 200OK 



Service 
Control 



5. SIP BYE (Reason) 



4. Debit and Reserve Units 
l^sponse (Service Termination i 



6.4xx, 5xx, 6xx (Error-Info) 
to reject the re-INVITE 



6. ACK 



7.SIP BYE (Reason) 



7. 200OK 



5. 200OK 



3. Debit and Reserve Units 
Request (UPDATE) 



5. SIP BYE (Reason) 



5. 200OK 



The SIP Session is released 



Figure B.3.2: Service Termination triggered by tlie 200OK response to a re-INVITE request within a 

confirmed SIP dialog 
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UE 



P-CSCF 



S-CSCF 



IMS-GWF 



DCS 



1 . Confirmed SIP dialog already established 



2. Service Control 
(Reauth. Trigger, 
Quota Expired...) 



5. SIP BYE (Reason) 



5. SIP BYE (Reason) 



5. 200 OK 



6. SIP BYE (Reason) 



6. SIP BYE (Reason) 



6. SIP BYE (Reason) 



6. 200 OK 



6. 200 OK 



6. 200 OK 



3. Debit and Reserve Units 
Request (UPDATE) 



4. Debit and Reserve Units 

Response (Service 
< T e rm i na tio n) 



5. 200 OK 



The SIP Session is released 



Figure B.3.3 : Service Termination triggered by the Charging Application procedures as defined in 

TS 32.299 [50] within a confirmed SIP dialog 
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B.4 Scenario 4 - Session Unrelated (ECUR): Service 

Termination on reception of an initial SIP non-INVITE 
Request 



UE 



P-CSCF 



S-CSCF 



IMS-GWF 



DCS 



1. SIP Request (e.g. SUBSCRIBE) 1. SIP Request (e.g. SUBSCRIBE) 



4. 4xx, 5xx, 6xx (Error-Info) 



4. 4xx, 5xx, 6xx (Error-Info) 



1. SIP Request (e.g. SUBSCRIBE) 



Service 
Control 



2. Debit and Reserve Units 
Request (INITIAL) 



3. Debit and Reserve Units 
Response (Service Termination) 



4. 4xx, 5xx, 6xx (Error-Info) 



Figure B.4.1 : Service Termination triggered by the reception of a non-INVITE SIP request 
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B.5 Scenario 5 - Session Unrelated (lEC): Service 

Termination on reception of an initial SIP non-INVITE 
Request 



UE 




P-CSCF 




S-CSCF 




IMS-GWF 




DCS 



1. SIP Request {e.g. SUBSCRIBE) 



1. SIP Request (e.g. SUBSCRIBE) 



4. 4xx,5xx,6xx (Error-Info) 



4. 4xx,5xx,6xx (Error-Info) 



1. SIP Request (e.g. SUBSCRIBE) 



Service 
Control 



2. Debit Units Request (EVENT) 



3. Debit Units Response (Service 
Termination) 



4.4XX, 5xx, 6xx (Error-Info) 



Figure B.5.1 : Service Termination triggered by the reception of a non-INVITE SIP request 
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